Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source device sdb2_crypt
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.
Reply to: