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