Dear Dennis,
On 2023-05-03 08:15, Dennis Filder wrote:
Control: reassign -1 cryptsetup-initramfs
X-Debbugs-CC: Pásztor János<pasztor.ja...@it.ppke.hu>
I having doubts that your issue is due to a bug because of this:
...
root@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
