I have a file system on LVM inside LUKS on a 2nd SSD that I'd like to mount at boot time. The OS boots fine on the main (non-LUKS) SSD.
/etc/crypttab contains a line mapping a UUID to a name, with no keyfile.
/etc/fstab contains a line mapping /dev/LVMvg/volume to /home/special
But I'm not asked for the passphrase at boot.
I can do it manually once booted (cryptdisks_start asks for the passphrase, decrypts it, and then LVM picks up the volumes enabling me to mount /home/special.) But I'd like all this to happen early in the boot.
How can I make the early processes ask me for the crypt password?
Thanks!
EDIT: Solved!
Thanks (blush) to man crypttab ... Add initramfs to the options field in crypttab does the trick. I was a bit confused though because man crypttab tells me that Systemd's crypttab is different and doesn't support the initramfs option... but I'm using systemd and it worked. Anyway, it did work. Phew.
Thanks for answers though!
9 Comments
eldavi@lemmy.ml · 2 pts · 46d
I'm going to be doing this in the next few days and I'm SO GLAD you posted the how it was solved.
For a second there I was afraid you were going to leave us hanging like they used to do on forums where they updated saying it was fixed but not how... Or worse yet w a dead link. Lol
nettie@lemmy.world · 2 pts · 45d
Good luck!
BillibusMaximus@sh.itjust.works · 2 pts · 46d
Caveat: I've used LUKS quite a bit, but never to do exactly what you're trying to do, so the following is a guess.
If the root disk was the encrypted one, the tooling would add scripts to your initramfs to handle the prompting and unlocking at boot.
Since it's not the root, those scripts may not be getting added.
I'm not sure about the "right" way to force it to add them, but you should be able to manually tweak your initramfs setup to add them.
nettie@lemmy.world · 1 pts · 46d
Thanks, I solved it by RTM-ing, see edit.
moonpiedumplings@programming.dev · 1 pts · 46d
It looks like KDE and linux mint have the ability to auto unlock and mount drives, according to this bug:
https://bugs.kde.org/show_bug.cgi?id=466731
Probably a feature of the desktop environment.
novafunc@discuss.tchncs.de · 1 pts · 45d
Not a DE thing. In /etc/crypttab, you can point to.a keyfile or password to unlock the disk.
So you unlock the OS disk, and on that now readable OS disk are keyfiles and passwords that then unlock the other disks.
akunohana@piefed.blahaj.zone · 1 pts · 46d
Maybe this: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS
But most importantly this: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader_2
It's the bootloader (configuration) that engages/prompts the LUKS partition.
Edit: the Arch wiki often (but not always) assumes that you are using systemd, so do make the appropriate adjustments according to what init system you are using! ☺️
nettie@lemmy.world · 2 pts · 46d
Thanks for your post. Yeah I've done encrypted OS partitions myself and it's worked fine - it's asked for the password. This was a bit different because I was needing something unlocked that - as far as the boot loader was concerned - was not needed for boot. I did find the solution though - see my edit in OP above.
akunohana@piefed.blahaj.zone · 2 pts · 46d
Ah, my bad. Cool that you got it working! And while it could be the "right" way, I wonder if crypttab is the only way to do this, or if it's possible to do decryption of a non boot volume as an option in a boot loader entry or in the kernel command line. Just thinking out loud. 🤣