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

[Pásztor János]

Dear Dennis,

On 2023-05-03 08:15, Dennis Filder wrote:
> Control: reassign -1 cryptsetup-initramfs
> X-Debbugs-CC: Pásztor János<pasztor.janos at it.ppke.hu>
>
> I having doubts that your issue is due to a bug because of this:
>
>> ...
>> root at asgard ~ # more /etc/initramfs-tools/hooks/crypttab-fix.sh
>> #!/bin/sh
>> cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
>> exit 0
>> ...
> Why did you add this?  Did you notice that during update-initramfs
> runs no cryptroot/crypttab file was placed into the initramfs?

I have got a crypttab file in initramfs, but the contents were not the 
same as on my booted machine.
The script is an attempt from a shutgun-debugging session with the goal 
to reach a stable boot process.

Please see the its contents in my previous reply to this case.

>   If yes
> then you should have investigated why not because it was indicative
> that something in your setup was broken enough for
> /usr/share/initramfs-tools/hooks/cryptroot to properly generate its
> part of the initramfs.  FYI: That script does not simply copy
> /etc/crypttab, but parses it and generates a sanitized version because
> it relies on /scripts/local-block/lvm2 which does not work with UUIDs
> (see #902943).  Sure enough your crypttab contains UUID= entries:
>
>> -- /etc/crypttab
>> 1Tnvme UUID=1cb8215e-4bb9-479b-ad06-36ae1b3fc957 none luks,discard
>> 4Tsolid UUID=2c3dd479-7f24-4aa9-8850-ee5e970e7d32 none luks

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.

See my modified /etc/crypttab below.

-------------------------8<----------------BEGIN------------------->8-----------

1Tnvme /dev/nvme0n1p3 none luks,discard
4Tsolid /dev/sdc1 none luks

-------------------------8<------------------END------------------->8----------- 


However this fails spectacularly, as during the boot process the 
ordering is not stable, sometimes it is sdb1 or sda1 instead of sdc1 :/

Also tried a mashup config

-------------------------8<----------------BEGIN------------------->8-----------

1Tnvme /dev/nvme0n1p3 none luks,discard
4Tsolid UUID=2c3dd479-7f24-4aa9-8850-ee5e970e7d32 none luks

-------------------------8<------------------END------------------->8----------- 


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


But the comments gave me a hint, so I have tried the `/dev/disk/by-` option

-------------------------8<----------------BEGIN------------------->8-----------

1Tnvme /dev/disk/by-id/nvme-Samsung_SSD_980_1TB_S649NF0RC06547P-part3 
none luks,discard
4Tsolid /dev/disk/by-id/ata-WDC_WD40EZRZ-22GXCB0_WD-WCC7K6YN7DZJ-part1 
none luks

-------------------------8<------------------END------------------->8-----------

And indeed, the crypttab in initramfs does not get mangled if I use this 
path specification.
But the problem still persists in its original form.

> Adding some kind of warning in a comment to the generated
> cryptroot/crypttab to not manually edit or overwrite it sure would
> have been helpful.  Or if that's not possible at least a brief README
> file in the same directory.  One could even lint for this during
> initramfs generation and emit a warning, e.g. with:
>
>    grep -e '\(etc\|cryptroot\)/crypttab' /etc/initramfs-tools/hooks/*
>
> Regards.

This day could hold only so much reboot...
During the weekend I will try to repro it in a VM, which would enable a 
better trial-error-inspect cycle.

Please let me know if you need any further information!

Regards,
János Pásztor