automount encrypted USB disk connected at boot

[tilmanschmidt]

Running openSUSE 11.4 64bit, Gnome desktop.

I have a 1 TB external USB disk with three partitions: one FAT, one ext3, and one LUKS encrypted ext3.
All of them are configured with useful volume labels.
When I connect that disk to the running system, everything works perfectly.
All three partitions are mounted automatically to subdirectories below /media named after their labels.
For the encrypted partition, I get a pop-up dialog asking me for the passphrase first.

It does not work quite as well if the disk is already connected and powered up at system start.
The two unencrypted partitions are still mounted automatically as before.
The encrypted partition, however, stays inaccessible.
I am never asked for the passphrase, and no icon appears for it on the desktop.

How can I get access to the encrypted partition in that situation?
Can I somehow make the passphrase dialog pop up automatically when I login with the external disk already connected, just as it would if I connected it later?
Lacking that, can I somehow manually trigger the mounting of the encrypted partition?

[malcolmlewis]

Hi
When you boot up the system, can you press the esc key and watch the messages. Maybe it’s pausing and asking for the paraphrase. Else check /var/log/messages to see if it’s asking for something.

[robin_listas]

On 2011-11-01 15:56, tilmanschmidt wrote:

> Lacking that, can I somehow manually trigger the mounting of the
> encrypted partition?

I can tell you how to manually mount that encripted partition, if you want
(as root). I don’t know how to tell the desktop to try again. Maybe you get
an icon for that partition, though - in gnome I think nautilus does that.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

[brunomcl]

Won’t mount -a as root do the trick?

[tilmanschmidt]

@malcolmlewis

When you boot up the system, can you press the esc key and watch the messages. Maybe it’s pausing and asking for the paraphrase.

I always set the “splash=verbose” boot option and watch the startup messages, anyway, because I like to know what my system is doing.
So I’m reasonably sure that it’s not asking anything on the text mode console.

@malcolmlewis

Else check /var/log/messages to see if it’s asking for something.

The whole automount process doesn’t leave that many traces in the logs, either way.

When I plug in the disk after logging in, /var/log/messages shows:

Oct 31 19:04:19 xenon kernel:   107.008051] usb 2-2: new high speed USB device number 6 using ehci_hcd
Oct 31 19:04:20 xenon kernel:   107.124084] usb 2-2: New USB device found, idVendor=1058, idProduct=1001
Oct 31 19:04:20 xenon kernel:   107.124091] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 31 19:04:20 xenon kernel:   107.124096] usb 2-2: Product: External HDD    
Oct 31 19:04:20 xenon kernel:   107.124099] usb 2-2: Manufacturer: Western Digital 
Oct 31 19:04:20 xenon kernel:   107.124103] usb 2-2: SerialNumber: 574341553433393130353730
Oct 31 19:04:20 xenon mtp-probe: checking bus 2, device 6: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-2"
Oct 31 19:04:20 xenon kernel:   107.140354] scsi10 : usb-storage 2-2:1.0
Oct 31 19:04:20 xenon mtp-probe: bus: 2, device: 6 was not an MTP device
Oct 31 19:04:21 xenon kernel:   108.144849] scsi 10:0:0:0: Direct-Access     WD       10EACS External  1.05 PQ: 0 ANSI: 4
Oct 31 19:04:21 xenon kernel:   108.146515] sd 10:0:0:0: Attached scsi generic sg6 type 0
Oct 31 19:04:21 xenon kernel:   108.148341] sd 10:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
Oct 31 19:04:21 xenon kernel:   108.149468] sd 10:0:0:0: [sdd] Write Protect is off
Oct 31 19:04:21 xenon kernel:   108.149479] sd 10:0:0:0: [sdd] Mode Sense: 21 00 00 00
Oct 31 19:04:21 xenon kernel:   108.150465] sd 10:0:0:0: [sdd] No Caching mode page present
Oct 31 19:04:21 xenon kernel:   108.150472] sd 10:0:0:0: [sdd] Assuming drive cache: write through
Oct 31 19:04:21 xenon kernel:   108.153588] sd 10:0:0:0: [sdd] No Caching mode page present
Oct 31 19:04:21 xenon kernel:   108.153597] sd 10:0:0:0: [sdd] Assuming drive cache: write through
Oct 31 19:04:21 xenon kernel:   108.193197]  sdd: sdd1 sdd2 < sdd5 sdd6 >
Oct 31 19:04:21 xenon kernel:   108.196683] sd 10:0:0:0: [sdd] No Caching mode page present
Oct 31 19:04:21 xenon kernel:   108.196689] sd 10:0:0:0: [sdd] Assuming drive cache: write through
Oct 31 19:04:21 xenon kernel:   108.196694] sd 10:0:0:0: [sdd] Attached SCSI disk
Oct 31 19:04:22 xenon kernel:   109.384213] EXT4-fs (sdd6): mounted filesystem with ordered data mode. Opts: (null)
Oct 31 19:04:40 xenon kernel:   127.848053] Intel AES-NI instructions are not detected.
Oct 31 19:04:40 xenon kernel:   128.106983] padlock_aes: VIA PadLock not detected.
Oct 31 19:04:41 xenon kernel:   128.387143] alg: No test for stdrng (krng)
Oct 31 19:04:41 xenon kernel:   128.461521] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
Oct 31 19:04:41 xenon kernel:   128.578608] padlock_sha: VIA PadLock Hash Engine not detected.
Oct 31 19:04:41 xenon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/3.0.8-capigig/kernel/drivers/crypto/padlock-sha.ko): No such device
Oct 31 19:04:42 xenon kernel:   129.420450] EXT3-fs: barriers not enabled
Oct 31 19:04:42 xenon kernel:   129.432757] EXT3-fs (dm-5): warning: checktime reached, running e2fsck is recommended
Oct 31 19:04:42 xenon kernel:   129.433666] kjournald starting.  Commit interval 5 seconds
Oct 31 19:04:42 xenon kernel:   129.434344] EXT3-fs (dm-5): using internal journal
Oct 31 19:04:42 xenon kernel:   129.434363] EXT3-fs (dm-5): mounted filesystem with ordered data mode

The USB and SCSI subsystems verbosely report detecting the disk.
A single line tells about the mounting of the unencrypted ext4 partition.
Half a dozen collateral messages show that something starts in-kernel AES encryption.
Then the device mapper unit containing the decrypted ext3 partition gets mounted.
The mounting of the FAT partition leaves no trace at all, though.

When the disk is connected at boot time, these messages appear in /var/log/boot.msg instead of /var/log/messages, I guess because everything happens before syslogd kicks in:

<6>    2.052012] usb 2-2: New USB device found, idVendor=1058, idProduct=1001
<6>    2.052016] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
<6>    2.052018] usb 2-2: Product: External HDD    
<6>    2.052021] usb 2-2: Manufacturer: Western Digital 
<6>    2.052023] usb 2-2: SerialNumber: 574341553433393130353730
<6>    2.102338] scsi6 : usb-storage 2-2:1.0
<5>    3.120662] scsi 6:0:0:0: Direct-Access     WD       10EACS External  1.05 PQ: 0 ANSI: 4
<5>    3.131142] sd 6:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
<5>    3.181384] sd 6:0:0:0: [sdc] Write Protect is off
<7>    3.191470] sd 6:0:0:0: [sdc] Mode Sense: 21 00 00 00
<3>    3.191474] sd 6:0:0:0: [sdc] Assuming drive cache: write through
<3>    3.203126] sd 6:0:0:0: [sdc] Assuming drive cache: write through
<6>    3.259013]  sdc: sdc1 sdc2 < sdc5 sdc6 >
<3>    3.270742] sd 6:0:0:0: [sdc] Assuming drive cache: write through
<5>    3.280928] sd 6:0:0:0: [sdc] Attached SCSI disk

Which looks almost the same, except this time there is no trace of filesystems getting mounted, not even the ones who do work.

[tilmanschmidt]

@brunomcl

Won’t mount -a as root do the trick?

No, mount -a only mounts the filesystems which are listed in /etc/fstab.
USB storage devices are usually mounted via udev, and I’d prefer to keep it that way.
Entering them in /etc/fstab wouldn’t work well because they may get a different device name each time, depending on the order in which they are detected.
Another advantage of mounting via udev is that it doesn’t require root privilege.

[robin_listas]

On 2011-11-01 19:36, tilmanschmidt wrote:

> Entering them in /etc/fstab wouldn’t work well because they may get a
> different device name each time, depending on the order in which they
> are detected.

That’s why we do not use device names any more in fstab.

> Another advantage of mounting via udev is that it doesn’t require root
> privilege.

You can use sudo.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

[hcvv]

@tilmanschmidt

No, mount -a only mounts the filesystems which are listed in /etc/fstab.
USB storage devices are usually mounted via udev, and I’d prefer to keep it that way.
Entering them in /etc/fstab wouldn’t work well because they may get a different device name each time, depending on the order in which they are detected.
Another advantage of mounting via udev is that it doesn’t require root privilege.

Then do not use device names in fstab, but e.g. the volume labels you mentioned (or any of the other methods available).
I see no reason why the type of connection (USB or not) should be paramount in the way one wants to mount. IMHO it is determined by the use of the device: permanently mounted from system start to stop, or dynamicaly (de)connected and assoiciated to a running GUI session of (one of)) the loged in user(s).

I know people are talking about “internal” and “external” disks, bur IMHO this is a misnomer. The system does not bother if the device is inside or outside of the iron/plastic box.

[tilmanschmidt]

@hcvv

Then do not use device names in fstab, but e.g. the volume labels you mentioned (or any of the other methods available).

As I wrote, I do not use fstab at all for the disk in question, and I intend to keep it that way as long as there’s no compelling reason for changing it.

@hcvv

I see no reason why the type of connection (USB or not) should be paramount in the way one wants to mount. IMHO it is determined by the use of the device: permanently mounted from system start to stop, or dynamicaly (de)connected and assoiciated to a running GUI session of (one of)) the loged in user(s).

I totally agree. USB is just an implementation detail.

So my question concerns the second case, a disk which is connected and disconnected dynamically, typically by the user which is, or shortly will be, logged on to the GUI. For that mode of operation, mounting via udev is IMHO better suited that mounting through an fstab entry. Specifically, my question concerns the border case where such a disk, which should be mounted via udev, happens to be already connected when the system starts. This may happen, and the system should be able to handle it consistently. So what do you propose as solution?

@hcvv

I know people are talking about “internal” and “external” disks, bur IMHO this is a misnomer. The system does not bother if the device is inside or outside of the iron/plastic box.

I disagree. It is common usage, and IMHO indeed quite acceptable, to label devices that may be connected and disconnected dynamically as “external”, and devices which will only be connected or disconnected when the computer is turned off as “internal”. Practice shows that devices which are mounted inside the main computer case are significantly less prone to be connected and disconnected dynamically than those with separate housing.

[hcvv]

I see we are on the same string of thought hen.

@tilmanschmidt

So my question concerns the second case, a disk which is connected and disconnected dynamically, typically by the user which is, or shortly will be, logged on to the GUI. For that mode of operation, mounting via udev is IMHO better suited that mounting through an fstab entry. Specifically, my question concerns the border case where such a disk, which should be mounted via udev, happens to be already connected when the system starts. This may happen, and the system should be able to handle it consistently. So what do you propose as solution?

My answer wil not help you much with tthe encrypted file system problem. But I guess that the udev mount will fail when mounting for a user that is not yet loged in. As that mounting is done co-working with the desktop (e.g. for non Linux file systems an owner is to be used).

@tilmanschmidt

I disagree. It is common usage, and IMHO indeed quite acceptable, to label devices that may be connected and disconnected dynamically as “external”, and devices which will only be connected or disconnected when the computer is turned off as “internal”. Practice shows that devices which are mounted inside the main computer case are significantly less prone to be connected and disconnected dynamically than those with separate housing.

When all people used the same definition as you post here, it would be OK (though I still would find it a misnomer, when you mean dynamicaly connecting a file system, say so, no need to add the word “external”). But in “common usage” all sorts of people seem to have a different view in their minds what this means and that sometimes creates big embarrassment. That at least is my experience after reading many threads here.

[robin_listas]

On 2011-11-02 03:16, tilmanschmidt wrote:

> As I wrote, I do not use fstab at all for the disk in question, and I
> intend to keep it that way as long as there’s no compelling reason for
> changing it.

Is it not enough that it does not work? >:-)

You either have care that it is not connected while booting, or make do
with the traditional method.

If you want the dynamic method to work, well, test the factory version, and
if that fails as well, report in bugzilla and hope it is solved for 12.2.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

[tilmanschmidt]

@robin_listas

On 2011-11-02 03:16, tilmanschmidt wrote:

> As I wrote, I do not use fstab at all for the disk in question, and I
> intend to keep it that way as long as there’s no compelling reason for
> changing it.

Is it not enough that it does not work? >:-)

Actually, no. The proposed change should also improve the situation.

Switching to mounting via fstab would either mean that the system boot will fail if the disk isn’t connected at startup (mount option “auto”) or that it is never mounted automatically and must always be mounted manually from the command line (mount option “noauto”). To be honest, neither of these two alternatives looks like an improvement over the current situation to me.

@robin_listas

You either have care that it is not connected while booting, or make do
with the traditional method.

There’s a third option: hacking the udev mechanism for mounting storage devices so that it can be triggered manually, or even better, automatically after a user logon. That shouldn’t be too difficult. In fact I had hoped that somebody would have done it already.

I think I’ll have a go at it myself. I don’t know much about the inner workings of udev yet, but that can be changed. The main obstacle, as usual, seems to be the lack of good documentation or knowledgeable people. Anybody know a good tutorial about udev debugging and/or a udev guru willing to answer some questions?

If not, there’s always UTSL. Thank God for Open Source.

[hcvv]

Well, the obvious interface for influencing the udev mechanism are the udev rules (in* /etc/udev*).

A bit more about how they work can be found on the internet, e.g. in http://reactivated.net/writing_udev_rules.html

[robin_listas]

On 2011-11-02 12:26, tilmanschmidt wrote:
>
> robin_listas;2399672 Wrote:
…

> Actually, no. The proposed change should also improve the situation.
>
>

There is yet no other proposed way that works “now”

There is an idea, but you have to find out how to do it yet.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

[tilmanschmidt]

@tilmanschmidt

There’s a third option: hacking the udev mechanism for mounting storage devices so that it can be triggered manually, or even better, automatically after a user logon. That shouldn’t be too difficult.

Ok, although I haven’t progressed much in my understanding of udev, I’m one step further. I found two ways to mount the encrypted partition when it isn’t mounted automatically:

a) In Nautilus, either select “Go To - Computer” from the menu bar or “Places” from the drop-down list above the left pane. The unmounted encrypted partition appears there as “1,0 TB Hard Disk: 322 GB encrypted” and can be mounted in its assigned place below /media via its context menu.

b) In a console window, run the command “gvfs-mount -d /dev/sdc5” (provided sdc5 is the device name the disk gets assigned.) That asks for the passphrase in the console window and then also mounts the partition in its assigned place.

Either way, you don’t need root privileges, and you don’t need to touch /etc/fstab and break automounting of the unencrypted partitions.

It isn’t completely automatic, but it is Good Enough™ for the time being, until I find a way to fully automate it.

[robin_listas]

On 2011-11-02 23:56, tilmanschmidt wrote:
> a) In Nautilus, either select “Go To - Computer” from the menu bar or
> “Places” from the drop-down list above the left pane. The unmounted
> encrypted partition appears there as “1,0 TB Hard Disk: 322 GB
> encrypted” and can be mounted in its assigned place below /media via its
> context menu.

I told you that.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

[tilmanschmidt]

@robin_listas

On 2011-11-02 23:56, tilmanschmidt wrote:
> a) In Nautilus, either select “Go To - Computer” from the menu bar or
> “Places” from the drop-down list above the left pane. The unmounted
> encrypted partition appears there as “1,0 TB Hard Disk: 322 GB
> encrypted” and can be mounted in its assigned place below /media via its
> context menu.

I told you that.

Ah, sorry for not giving credit. Indeed, your remark:

Maybe you get an icon for that partition, though - in gnome I think nautilus does that.

in one of your replies yesterday did help putting me on the right track. Thanks for that.

[robin_listas]

On 2011-11-03 01:16, tilmanschmidt wrote:
> in one of your replies yesterday did help putting me on the right
> track. Thanks for that.

Welcome.

I have been reporting bugs on encripted disks handling over several years,
till now that it works, and even though I never automount them I knew the
feature was there. But the details of automount I ignore, so I could not
tell you exactly where to click.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)