Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #229140 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source device  sdb2_crypt David Christensen <dpchrist@holgerdanske.com> - 2020-11-28 06:30 +0100
    Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source  device sdb2_crypt David <bouncingcats@gmail.com> - 2020-11-28 07:50 +0100
      Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source  device sdb2_crypt David <bouncingcats@gmail.com> - 2020-11-28 08:20 +0100
      Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source  device sdb2_crypt David Christensen <dpchrist@holgerdanske.com> - 2020-11-28 09:50 +0100
        Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source  device sdb2_crypt Andrei POPESCU <andreimpopescu@gmail.com> - 2020-11-28 10:10 +0100
          Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source  device sdb2_crypt David Christensen <dpchrist@holgerdanske.com> - 2020-11-28 19:40 +0100
    Re: debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source  device sdb2_crypt David Wright <deblis@lionunicorn.co.uk> - 2020-11-29 04:30 +0100

#229140 — debian-10.6.0-amd64 cryptsetup: Waiting for encrypted source device sdb2_crypt

debian-user:

I have a desktop computer with an Intel DQ67SW motherboard and an Intel 
SSD 520 Series 60 GB system drive connected to the first SATA port.


I downloaded:

     debian-10.6.0-amd64-xfce-CD-1.iso

I verified the GPG signature on the checksum file and verified the 
checksum on the ISO file.


I burned the ISO file to a USB flash drive and verified the checksum of 
the burned image.


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').


I learned a long time ago that the system drive should be 'sda' during 
installation, or bad things can happen.


I tried moving the USB flash drive to various USB ports and changing 
CMOS Setup settings, but was unable to find a configuration whereby the 
system drive was 'sda' and the USB drive was 'sbd'.


So, I proceeded with the install.


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


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


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)?  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)?


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.


Comments?  Explanations?  Suggestions?


David

[toc] | [next] | [standalone]

#229141 — 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.

[toc] | [prev] | [next] | [standalone]

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

On Sat, 28 Nov 2020 at 17:39, David <bouncingcats@gmail.com> wrote:
> On Sat, 28 Nov 2020 at 16:22, David Christensen <dpchrist@holgerdanske.com> wrote:

> 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.

I checked some of my notes (my situation was different) and I may
have mis-remembered and perhaps given bad advice.
I don't know if cryptsetup can be run at that point in busybox.

I did reach the goals you want, but I don't exactly recall enough to
provide you a detailed method.

> 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 am sure about this:
A crypt device mapping <name> cannot be changed when the device is
open (and therefore cannot be changed from any OS inside it).

So you need a separate rescue environment that has cryptsetup available.
If you don't attempt to change the crypt device <name>, then
it might be possible to just 'cryptsetup open' it in some rescue environment
and then fix the devices as I described, but not changing the names.
You might also need to chroot, see next paragraph.
Also the rescue environment needs to use the same kernel.

My notes tell me that to successfully change the <name>, I needed to
do all that, plus chroot into the crypt device before running
'update-initramfs'.
I don't have time to spend figuring out a recipe solution for you, but hopefully
these clues help if you are interested in finding your own way towards
a solution.

[toc] | [prev] | [next] | [standalone]

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

On 2020-11-27 22:39, David wrote:

Thanks for the reply.  :-)


> On Sat, 28 Nov 2020 at 16:22, David Christensen
> <xxxxxxxx@xxxxxxxx.com> wrote:

Please configure your mail client so that it does not put the sender's 
e-mail address into the body of your reply.


>> 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

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

> 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.

> 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.

At that point in the boot process, I have already entered the root 
partition dm-crypt passphrase.  So, the root filesystem, /etc/crypttab, 
and /etc/fstab are available to the bootloader; if it cared to look.


I can ignore the crypttab(5) target values; it's the source device value 
of '/dev/sdb2' in /etc/crypttab that changes once I remove the 
installation USB flash drive and reboot.  Caching this value in a 
/boot/* file rather than reading it from the canonical source is bad 
engineering.


> 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 suppose I could waste more time working around flaws in Linux and/or 
Debian.


But, I have already built a graphical workstation using FreeBSD.


> I use UUID= syntax in my etc/crypttab to specify devices.

I tried crypttab(5) source devices of 'UUID=...' in the past for 
encrypted swap paritions; they did not work.  /dev/disk/by-partuuid/* works.


David

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Sb, 28 nov 20, 00:46:22, David Christensen wrote:
> On 2020-11-27 22:39, David wrote:
> 
> Thanks for the reply.  :-)
> 
> 
> > On Sat, 28 Nov 2020 at 16:22, David Christensen
> > <xxxxxxxx@xxxxxxxx.com> wrote:
> 
> Please configure your mail client so that it does not put the sender's
> e-mail address into the body of your reply.

Our e-mail addresses are posted in clear in the list archives[1], if 
this is what you are worried about.

[1] https://lists.debian.org/debian-user/2020/11/msg00748.html

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

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

On 2020-11-28 01:03, Andrei POPESCU wrote:

> On Sb, 28 nov 20, 00:46:22, David Christensen wrote:

>> On 2020-11-27 22:39, David wrote:

>>> On Sat, 28 Nov 2020 at 16:22, David Christensen
>>> <xxxxxxxx@xxxxxxxx.com> wrote:
>>
>> Please configure your mail client so that it does not put the sender's
>> e-mail address into the body of your reply.
> 
> Our e-mail addresses are posted in clear in the list archives[1], if
> this is what you are worried about.
> 
> [1] https://lists.debian.org/debian-user/2020/11/msg00748.html
> 
> Kind regards,
> Andrei

That is a Debian issue.


David

[toc] | [prev] | [next] | [standalone]

#229160 — 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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web