3

I have an encrypted Ubuntu 14.04 Desktop setup. The encrypted root partition is created using the Ubuntu installer default parameters (choices "Erase disk and install Ubuntu" and "Encrypt the new Ubuntu installation"). This part works fine (it asks for password at boot and opens the root and swap partitions).

Later I added a second drive, separately encrypted with a keyfile stored on the root partition. The intention was to make it open automatically as soon as root partition is open. To that end, the second drive was added to crypttab (by UUID) and its encrypted filesystem -- to fstab (by label, mount point /stg).

On boot, after entering the main decryption password, I get this: An error occurred while mounting /stg. Press S to skip mounting or M for manual recovery.

The strange thing is, if I press M and simply run mount -a, it just mounts successfully. I do not see anything suspicious in /var/log/syslog.

What's up with that? What can I check to diagnose the problem?


[UPD - added some details] The drive sdb has an MBR partition table with one partition. The encrypted file system was initialized using the following commands:

cryptsetup luksFormat /dev/sdb1 /root/stg.key
cryptsetup luksOpen /dev/sdb1 stg_crypt -d/root/stg.key
mkfs.ext4 /dev/mapper/stg_crypt -Lstg-tmp

/etc/crypttab (actual uuids replaced with text "uuid-of-..." for brevity):

# this entry was created by Ubuntu installer
sda5_crypt UUID=uuid-of-sda5 none luks,discard

# this entry was added by me
stg_crypt  UUID=uuid-of-sdb1 /root/stg.key luks,discard

/etc/fstab:

# these entries were created by Ubuntu installer
/dev/mapper/ubuntu--vg-root   /      ext4 errors=remount-ro 0 1
UUID=uuid-of-sda1             /boot  ext2 defaults          0 2
/dev/mapper/ubuntu--vg-swap_1 none   swap sw                0 0

# this entry was added by me
LABEL=stg-tmp                 /stg   ext4 errors=remount-ro 1 2
1

Funnily enough, replacing the label reference in fstab with device path fixes the problem! I.e.: LABEL=stg-tmp changed to /dev/mapper/stg_crypt.

I also tried the UUID reference, it didn't work. So apparently the LABEL and UUID references during boot work for physical partitions but do not work for encrypted partitions. But they do work in mount -a for any partitions.

This is not very satisfactory as solutions go (e.g. it lacks an explanation) but it solves the issue at hand so I guess it's ok for now..

0

First thought is the intramfs does NOT see the keyfile (normal behaviour)

couple fixes include:

adding/creating a fallback passphrase for /stg like mentioned here

Adding Fallback to Luks (scroll down to Adding Fallback passphrase section)

adding dd if=/dev/usbkey bs=512 skip=4 count=8 | cryptsetup luksOpen /dev/md0 luksVolume --key-file=- && mount /dev/mapper/luksVolume /mnt/

at creation or using cryptsetup-reencrypt (in the repos but not default installed)

  • But it does open the sdb1 volume automatically, so it must be able to see the keyfile. It just doesn't mount the decrypted filesystem until I run mount -a in the repair console. (Or, for that matter, press S instead of M, complete the boot and run sudo mount -a in a regular terminal). – atzz Apr 16 '15 at 22:32
  • tehn add mount -a to your mount/boot scripts (cpio hooks even maybe ) – linuxdev2013 Apr 16 '15 at 22:34
  • Where to? I'd need a place after the root partition is open but before the mount checker runs (or whatever displays the modal error at boot); could you please suggest one? Also it would be nice to understand why it fails to mount. – atzz Apr 16 '15 at 22:47
  • the keyfile merely allows sudo cryptsetup luksOpen {options} /dev/{by-uuid} {Mounting name} you are desiring that AND sudo mount /dev/mapper/{VGname-LVNAME} /stg} throwing this in /etc/fstab should fix that (however if it is ever not attached on boot it will throw errors – linuxdev2013 Apr 16 '15 at 22:49
  • a valid line in /etc/fstab for this would look like: {$UUID} /stg {$fstype} none luks,noearly (the noearly would tell it essentially if not present move along don't fail out) – linuxdev2013 Apr 16 '15 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.