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

[Pásztor János]

Control: tag -1 - unreproducible - moreinfo

Dear Dennis,

On 2023-05-05 18:10, Dennis Filder wrote:
> 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.
>

I think that we can let that option(libblkid changes) go, as I have 
managed to reproduce this issue in a virtual machine, freshly installed 
from `firmware-11.7.0-amd64-netinst.iso`

With that we have get rid of:
- the possible fallout from the history of my old install
- the underlying hw dependencies

The big lesson what I have learned from it that you need to install and 
enable plymouth to have the magic password sharing between the LUKS 
devices. If you do not have that, then it will ask the pw twice (on 
bullseye) but besides that it boots properly

The machine and the disks are having two snapshots named 'good' and 
'bad' so it is easy to jump between the states.
I am willing to share with you the VM(disks + virsh dump) via a 
filesharing service. Would you be interested in it?

Regards,
János Pásztor