Control: tag -1 - unreproducible - moreinfo
Dear Dennis,
On 2023-05-05 18:10, Dennis Filder wrote:
X-Debbugs-CC: Pásztor János <pasztor.ja...@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
