On Mon, Feb 03, 2025 at 10:39:25PM +0000, Automætic wrote: > Hi, > > I'm configuring a new Debian installation on my workstation, with both the > /boot partition and the root filesystem encrypted: > - /dev/nvme0n1p1 -> /EFI > - /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot > - /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes > > The system boots, but requires entering the /boot password twice: > Once for GRUB, and once again during systemd initialization.
I think the solution is to not encrypt the /boot partition. That partition shouldn't contain anything sensitive on it anyways. In order to avoid decrypting it twice, there would need to be some mechanism for GRUB to pass the encryption information through to the Linux kernel system or initrd environment and I am not aware of any such mechanism. GRUB passes the kernel command-line which is public and visible under /proc/cmdline, details on the initrd that was loaded, and a few other parameters like memory size and video mode, but there's no standard way to pass extra details like crypto keys that need to be kept secret. With that said, don't take my word for it as I may not be completely informed. However, I don't think it'll likely be worth the effort, especially when things go wrong. I did take a look at the GRUB 2 source code and discovered some support for an MBR-encrypted by TrueCrypt, but it seems to be strongly linked with some kind of El Torito CD-ROM boot image and is likely more complex than is worth it. Feel free to prove my earlier assertion wrong. :-) -Loren > > Both devices are properly configured in /etc/crypttab with the UUIDs for > /dev/nvme0n1p2 and /dev/nvme0n1p3 respectively (as outputted by blkid). > GRUB_CMDLINE_LINUX contains the correct cryptdevice parameters for both > partitions, also with UUIDs. > > I checked the initramfs contents using 'unmkinitramfs' in /tmp/initramfs/ to > review main/cryptroot/crypttab, but it only contains an entry for lvm_crypt, > boot_crypt is missing. > That leads me to believe that after GRUB hands off control to the kernel, the > boot_crypt mapping is lost. > Systemd then attempts to decrypt boot_crypt again. > > Things I attempted: > 1. Systemd unit overrides to prevent the second decryption > 2. Moving the boot_crypt entry to the first line in crypttab, just in case > the cryptroot hook located at /usr/share/initramfs-tools/hooks/cryptroot > processes only the first entry. Of course, that didn't do anything - Debian > is pretty stable after all. > 3. Various initramfs configuration attempts > > Every time after making changes, I executed: > update-initramfs -u -k all > grub-install --target=x86_64-efi --efi-directory=/efi (I deleted my old > /boot/efi folder and remapped the /dev/nvme0n1p1 device to /efi in /etc/fstab > and as far as I can see, it works fine) > update-grub > reboot now > > Very, very often, my changes resulted either in timeouts and /boot not being > mounted, or the overrides not working. > > So here are some questions I need help with: > 1. Why isn't a crypttab entry for boot_crypt included in the initramfs? > 2. Is there a recommended way to preserve the device mapping from GRUB? > 3. Is this setup even supported/recommended? > > System details: > Kernel: 6.1.0-30-amd64 > Debian version: 6.1.124-1 (2025-01-12) x86_64 GNU/Linux > 'dpkg -l | grep -E "grub|cryptsetup" outputs the following packets: > cryptsetup, cryptsetup-bin, cryptsetup-initramfs, grub-common, > grub-efi-amd64, grub-efi-amd64-bin, grub-efi-amd64-signed, grub2-common and > libcryptsetup12:amd64 > > I really hope you can help me. > Best regards, > Automætic -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ IRC: penguin359 Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA
signature.asc
Description: PGP signature
