I'm rather hazy on this as I haven't yet tried encrypting /, but only /home and swap.
On Fri 27 Nov 2020 at 21:22:24 (-0800), David Christensen wrote: > The motherboard firmware is configured for BIOS mode. When I ran the > Debian Installer (d-i), it came up in BIOS mode. I choose 'manual' > partitioning: > > Encrypted volume (sdb2_crypt) - 1.0 GB Linux device-mapper (crypt) > #1 1.0 GB f swap swap > Encrypted volume (sdb3_crypt) - 12.0 GB Linux device-mapper (crypt) > #1 12.0 GB f ext4 / > SCSI5 (0,0,0) (sdb) - 60.0 GB ATA INTEL SSDSC2CW06 > #1 primary 999.3 MB B F ext4 /boot > #2 primary 1.0 GB K crypto (sdb2_crypt) > #3 primary 12.0 GB K crypto (sdb3_crypt) > 46.0 GB FREESPACE > […] > Upon rebooting, I entered the LUKS passphrase for sdb3_crypt. > > Boot continued, and then then hung at: > > cryptsetup: Waiting for encrypted source device sdb2_crypt > > After a timeout, the boot manager started BusyBox. As expected, the > system drive is now /dev/sda. > > I mounted sdb3_crypt at /mnt. I commented out the 'sdb2_crypt' entry > in crypttab(5) > > #sdb2_crypt /dev/sdb2 /dev/urandom cipher=aes-xts-plain64,size=256,swap > > I commented out the 'sdb2_crypt' entry in fstab(5). > > #/dev/mapper/sdb2_crypt none swap sw > > I then rebooted. Same problem: > > cryptsetup: Waiting for encrypted source device sdb2_crypt So the values in /etc/crypttab are not correct. I think you can override them by editing in grub, inserting cryptopts= in the commandline. You might use cryptopts=source=/dev/sda3. > It appears: > > 1. d-i still puts the kernel enumeration device node for random > encrypted partitions into crypttab(5). This is brittle, and fails if > the device node changes. > > A better solution is use one of the /dev/disk/by-*/* nodes. For example: > > sdb2_crypt /dev/disk/by-partuuid/007a0565-02 /dev/urandom > cipher=aes-xts-plain64,size=256,swap Agreed. Perhaps the reason it didn't is a hangover from the days of MBR disks which had no PARTUUID, and it's not been updated. I actually use a setup where the first 1MB of my swap partitions are a filesystem, exposing its LABEL. So my crypttab line is swap LABEL=swanswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 But I set that up post hoc rather than during installation. > 2. The Debian boot loader does not read crypttab(5) and/or fstab(5) > from the root partition (?!!!). > > Does Debian put these settings in initrd(4)? I don't know, but I would assume so. As I don't encrypt root, things like the crypt modules aren't in my initrd (and I get warned about that when it's rebuilt), but the place where the sole (I assume) crypttab line would be is (again, I assume) -rw-r--r-- 0 Sep 19 14:56 main/cryptroot/crypttab where main is the unpacked initrd's second part. > Do I need to run > update-initramfs(8) in the bootloader BusyBox and/or d-i rescue shell > if I change crypttab(5) and/or fstab(5)? I think so. AFAIK (but have never tested), once the system is up, you can correct the files and then rebuild the initrd. ISTR reading somewhere that it's the files that are used to build it, and not the current actuality, if you get my drift. If everything looks good when you inspect the new initrd with unmkinitramfs, then you should be able reboot. (Guessing again, so test with a system that's had no time spent configuring it.) > A better solution is to put the relevant information in exactly one > location -- /etc/crypttab and /etc/fstab -- and read it from > everywhere; including the bootloader. My guess (and it is just that) is that the initrd scripts don't want to have to parse some idiosyncratic user's crypttab and fstab, but use unadorned versions that are straightforward to parse. I can't test this guess because my cryptroot/crypttab and fstab are empty, and crypttab absent, for obvious reasons. Cheers, David.
