1

I would like to automatically decrypt /dev/sdb3 at boot with a keyfile located on /dev/sda5 which is a (passphrase-)encrypted partition. By "automatically", I mean "at boot, after being prompt for /dev/sda5 passphrase".

I am on debian stretch, and currently have this setup:

/etc/crypttab:

sda5_crypt UUID=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa none luks
sdb3_crypt UUID=bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb /etc/sdb3_key luks

/etc/fstab:

/dev/mapper/lv_sda5-lv_rootfs               /               ext4            discard,noatime,nodiratime,errors=remount-ro    0       1
UUID=cccccccc-cccc-cccc-cccc-cccccccccccc   /boot           ext2            noatime,nodiratime                              0       2
/dev/mapper/lv_sdb3-lv_home                 /home           ext4            defaults                                        0       2
/dev/mapper/lv_sdb3-lv_swap                 none            swap            sw                                              0       0

From now, I get prompted at boot for my passphrase to decrypt /dev/sda5, then I get the following message repeting for about 30 seconds

WARNING: Failed to connect to lvmetad. Falling back to device scanning.

Volume group "lv_sdb3" not found

Cannot process volume group lv_sdb3

Until I eventually get

Gave up waiting for suspend/resume device

/dev/mapper/lv_sda5-lv_rootfs: clean, ...

And my debian boot up perfectly, my /home and SWAP beeing correctly mounted.

How can I correctly achieve that ?

Edit

It seems the problem comes from lvm and isn't related to /etc/crypttab, /etc/fstab. Removing sdb3_crypt entries from /etc/crypttab and /etc/fstab doesn't change the error message loop. (I update-initramfs and update-grub for that changes to be repercuted on the /boot/initrd)

Now I'm wondering how the initramfs can be aware that there exists a lv_sdb3 volume group. I set use_lvmetad = 0 in /etc/lvm/lvm.conf, ran pvscan --cache which only finds lv_sda5 volume group since I did not open /dev/sdb3 LUKS partition. So where does the initramfs reads the /deprecated/ information about lv_sdb3 volume group ?

Improve this question
4
  • If you automate this step just remove the password? You're essentially disabling it anyway. Except maybe if you consider using an USB key but even than you could just put the key file on it. If everything is mounted correctly you probably already have some procedure to auto decrypt that's just later in the boot process.
    – Seth
    Commented Apr 18, 2017 at 10:38
  • I don't want to use an USB key to decrypt my partitions, so I use the passphrase to unlock my / mountpoint, mounted from /dev/sda5. I don't see why you said I'm essentially disabling it anyway. Keyfile to unlock /dev/sdb3 is locate on /, hence I need to unlock /dev/sda5 fisrt.
    – omega
    Commented Apr 18, 2017 at 12:17
  • As it is your initial statement can be read such as that the keyfile is password protected while the location of the key file itself is unprotected. Hence if you included the password during boot in an automated fashion there would be no reason for the encryption. So if I understand it correctly you're having an issue where your system can't read the key file during boot after you unlocked the primary system partition using a password but after boot sdb3 is successfully mounted? So you either need a hint where/how the unlock happens or how to do it properly during boot?
    – Seth
    Commented Apr 18, 2017 at 12:37
  • Exactly, I've made my description a little bit clearer according to your comment.
    – omega
    Commented Apr 18, 2017 at 14:30

1 Answer 1

Reset to default
0

Dumping /boot/initrd with zcat revealed lv_sdb3 appears once in clear ascii in the form RESUME=/dev/mapper/lv_sdb3-lv_swap

This can be removed by moving /etc/initramfs-tools/conf.d/resume to a backup directory, then update-initramfs -u -k all to rewrite /boot/initrd. Now the boot process goes without error and without the time-consuming loop !

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .