[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source device sdb2_crypt



On Sat, 28 Nov 2020 at 16:22, David Christensen
<dpchrist@holgerdanske.com> 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
>
> Note that the system drive is 'sdb' (the USB drive was 'sda').

[...]

> 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

[...]

> The Debian boot loader does not read crypttab(5) and/or fstab(5)
from the root partition (?!!!).

Hi,

At that point in the boot process, the root partition device has
not been mounted and so can't be read. Especially not if it is
encrypted.

> Comments?  Explanations?  Suggestions?

The <name>s referred to in 'man cryptsetup' are arbitrary
and are set by the 3rd argument of the 'cryptsetup open'
command. You can choose anything you want whenever you
run that command. The installer chose sdb2_crypt and sdb3_crypt,
so those names became baked into 'cryptsetup open' commands
in the initramfs, as well as in /etc/crypttab.

That default naming by the installer is understandable, but also
a bit irritating if for some reason it becomes mismatched when
the device name changes. That can be fixed as follows.

What you need to do is get the system up and running in the
configuration you want, by handling the timeouts and running
'cryptsetup open' (with whatever <names> and devices you
like to use) in busybox, as you described doing. The <name>s
you enter do not need to match any used previously. When
you run 'cryptsetup open' you are *creating* a new mapping
so you can use whatever name you like.

Once the system is up and running in the configuration you
want, make sure the same <names> and any device specifications
you like are used in /etc/crypttab. The rootfs device must also be
correct in /etc/fstab.

Then, run update-initramfs whose scripts will read those two files
and should update your initramfs with appropriate 'cryptsetup open'
commands and arguments so that things work properly at the next boot.

I hope this helps you move forward. I use UUID= syntax in my
etc/crypttab to specify devices.


Reply to: