On Wed, Jul 02, 2025 at 01:00:39AM +0200, Guilhem Moulin wrote:
[...]
> > 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.
> > […]
> > 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).
> > […]
> > 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.
>
> AFAICT it doesn't hang at early boot (initramfs) stage, but rather after
> the system has been handed over to systemd.
I don't think so. I think I've failed to properly communicate the crucial
point of my story ;-) Let me reiterate:
> 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.
> 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 (?). 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.
The call I've did is
# cryptsetup open --type=luks1 --disable-locks --disable-keyring \
--key-slot=0 /dev/nvme0n1p2 boot-crypt
Actually all the options make no difference - I've tried different
combinations of them - the program hangs at exactly the same syscall
after the device is opened, it can be seen in the output of
# dmsetup ls
but it still has no node under /dev/mapper.
Hence I'm inclined to think it's still an "early boot" issue (however moot
this term is).
> Do you have systemd-cryptsetup installed? (See the NEWS entry for
> systemd=256-2, which I guess should be in the release notes too.)
Thanks, I've try to research this ASAP.
I think it would be interesting to record what processes are running when
that "bash-as-init-process" get started.
> > 1. https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
>
> I need to review and update this page
Oh, I've now noticed you're the author of this manual.
That's a good manual indeed, kudos for this work!
> GRUB can open LUKS2 devices these days.
I've did a quick research of this topic after I've hit the regression we're
discussing, and it seems that the support is still incomplete [2]. In
particular, it appears one has to use PBKDF for key material derived from
passwords as the version of libgcrypt used by GRUB does not support argon2id
which seems to be the default for this in cryptsetup for LUKS2. IOW, extra
care must be taken by the user when setting up a LUKS2-formatted /boot.
2. https://savannah.gnu.org/bugs/?55093
