[pkg-cryptsetup-devel] Bug#1034836: {Spam?} Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell

[Dennis Filder]

X-Debbugs-CC: Pásztor János <pasztor.janos at it.ppke.hu>

On Wed, May 03, 2023 at 11:20:07PM +0200, Pásztor János wrote:
> I have checked #902943 and the fine print from
> /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
> Based on that I have made an attempt to replace the UUIDs with
> `traditional` disk device paths.
>
> [...]
>
> However this fails spectacularly, as during the boot process the
> ordering is not stable, sometimes it is sdb1 or sda1 instead of sdc1
> :/

If your device order is not stable during boot you need to use
PARTUUID instead of UUID.  You might argue that you should be able to
use UUID because it worked before Bookworm if you overwrote the
crypttab.  However, it might be that your LUKS containers were created
with an old version of cryptsetup that did not wipe the start of the
partition properly.  libblkid has had "behavioural changes" in the
past under such circumstances wrt. to block device probing and making
decisions [1].  It might be that whatever component is used to create
/dev/disk/by-* symlinks in the initramfs has changed behaviour, too.
According to your initramfs.debug log it's systemd-udevd.

    + /scripts/init-top/udev
    Starting systemd-udevd version 252.6-1

You'd have to try to get access to its log output.

You should also take copies of the first 1 MiB of your partitions that
hold the LUKS containers so libblkid (or whatever the culprit) can be
debugged with before you overwrite anything.  You'll have to provide
copies of some sort if you want someone else to debug this for you --
no idea how to sanitize/dekey them.  "cryptsetup luksErase" might
render the LUKS header unrecognizable.  You'll have to try it out.

If you feel like it you can investigate further with:

  LIBBLKID_DEBUG=all blkid -p
  lsblk -o NAME,SIZE,TYPE,UUID,PARTUUID

The next-heavier cannons would be ltrace/strace and gdb.

> But with this I am back at the original issue.
>
> During this I have spotted an interesting thing.  Even tough I put
> `traditional` disk device paths into /etc/crypttab, the generated
> initramfs has the UUID version of it, even after multiple
> regeneration!
>
> Going even forward, I have seen this in the source code of
> `/usr/share/initramfs-tools/hooks/cryptroot`: https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/latest/debian/initramfs/hooks/cryptroot#L43
> That contradicts with your previous statement of no UUID shall be present in
> crypttab

Oops, I was looking at a wrong version of the file.

Regards.

1: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/428435