Hi! I've hit a regression after upgrading my Debian 12 laptop to Trixie - in short, cryptsetup hangs at *early* boot stage when it apparently trying to create a device mapper node for a LUKS1 device it successfully opened. LUKS2 devices behave just fine.
I'm not sure what package to file a bug against, and what should be its
severity, so I'm going to explain the problem and ask for suggestions.
I have a full-disk encryption set up in a custom way along the lines of [1].
Basically, the setup is as follows: the single NVMe SSD device has 4
partitions in it:
- An unencrypted EFI boot partition.
- A LUKS1-encrypted ext4 /boot.
- A LUKS2-encrypted / (root), and
- A LUKS2-encrypted swap.
All LUKS-encrypted partitions have two key slots, one of which contains key
material derived from a password, and another - a randomly-generated key. All
those randomly-generated keys are stored in the initrafms image, so at boot
GRUB asks for the password to open /boot, then reads the kernel and the
initramfs off it and then the initramfs machinery handles the rest.
I've used this scheme on my laptop since, I think, Debian 10, it successfully
survived multiple system upgrades, but after upgrading to Trixie, the system
won't boot in the following way:
1. GRUB asks for the password and successfully opens /boot and starts the
boot process.
2. Then the boot process hangs for a while and then fails with the message
telling it failed to bring up the /boot partition and hence the
local-fs.target failed to be brought up, as well - bailing into the
emergency mode (which was unusable as I had root account with the locked
password, but this is another story).
I've noticed that the boot process brings up the LUKS2-encrypted boot parition
just fine 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.
The most weird thing is that if I comment out a line for that /boot
partition in /etc/fstab so that it's not attempted to be brought up at boot
and then manually open the device using cryptsetup after the system as
booted - it gets opened just fine. In other words:
- GRUB opens a LUKS1-encrypted device successfully.
- cryptsetup running at boot opens it OK but hangs at creating the
/dev/mapper node for this device - while having no problems with
LUKS2-encrypted devices.
- cryptsetup running after boot opens the device OK and creates a
/dev/mapper node for it successfully.
I've attached the output generated by `strace -f` with the cryptsetup
hanging at boot. I've verified that it always hangs in the same syscall.
So, can anyone please advice what package should I file a bug against and what
should be its severity?
Please CC me as I'm not subscribed.
1. https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
cs-hang.log.gz
Description: application/gzip
