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

Re: Trixie: cryptsetup hangs at boot when trying to create a device file via device mapper



On Wed, 02 Jul 2025 at 13:13:39 +0300, Konstantin Khomoutov wrote:
> On Wed, Jul 02, 2025 at 01:00:39AM +0200, Guilhem Moulin wrote:
>> I've noticed that the boot process brings up the LUKS2-encrypted root
>> parition just fine
>
> In my original mail I've mistakenly said "boot" there ^, but in fact it was
> the root partition.

Devices holding the root FS and the resume device are unlocked at early
boot stage.  Those holding /boot are normally not (because /boot is only
needed later in the boot process), and instead unlocked by systemd.  I
believe LUKS1 vs LUKS2 is a coincidence here; what matters instead is at
which stage each device is unlocked.

>> and tried to debug the boot process by booting the kernel with the
>>
>> root=/dev/mapper/root-crypt init=/usr/bin/bash
>>
>> arguments and then trying to open the LUKS1-encrypted /boot by hand.
>>
>> Here is what happens:
>>
>> - cryptsetup is able to verify the password used for one of the key slots
>>  just fine.
>>
>> - But when I run it to actually open the device it
>>
>>  1. Successfully opens the device and creates a node available via
>>     dmsetup (sorry, I don't know the correct terminology - I mean, one
>>     can see the new device by running `dmsetup ls` and mount it as
>>     /dev/dm-2).
>>
>>  2. It then hangs dead - apparently when attempting to create a node
>>     under /dev/mapper.
> 
> So, the kernel gets booted with /usr/bin/bash as its init process, and so I
> assume there are no parts of systemd running - except maybe something from
> initrafms (?).

Since you get to to the point where execution is handed over to init=/usr/bin/bash
or init=/sbin/init it is *not* an early boot issue.

> Still, in this scenario, the LUKS2-formatted root partition
> gets brought up just fine and has a node under /dev/mapper created for it just
> fine (and it allows the root= kernel argument to work in my case), but a
> manual attempt to bring up the LUKS1-formatted /boot partition hangs.

Probably not for the same reason though (and FWIW assuming this is a
production system, this was perhaps not a good idea to attach that
strace output to a public mailing list).  I'm not sure how init=/usr/bin/bash
interacts with udev, but cryptsetup seems to hang while waiting for the
udev cookie (`cryptsetup --debug` output would have been more useful and
less risky than a strace output).  Does it still hang when you set the
environment variable `DM_DISABLE_UDEV=y`?

Either way, experimenting with init=/usr/bin/bash and the cryptsetup(8)
executable is not a reproducer for your issue since because you end up
in a very different environment.  I think systemd doesn't hang while
waiting for the udev cookie, but instead fails because it lacks
cryptsetup integration or another unrelated reason.

> Hence I'm inclined to think it's still an "early boot" issue

No it's not.

>> Do you have systemd-cryptsetup installed?  (See the NEWS entry for
>> systemd=256-2, which I guess should be in the release notes too.)

You need to install the systemd-cryptsetup binary package to let systemd
automatically unlock your boot device.  See #1079644 or #1076208.

If you have systemd-cryptsetup installed, then increasing the log level
might shed some light about what is going on, see
https://freedesktop.org/wiki/Software/systemd/Debugging/ .

-- 
Guilhem.

Attachment: signature.asc
Description: PGP signature


Reply to: