On 2023-08-30 17:10, Andrei Borzenkov wrote:
On 30.08.2023 01:07, Carlos E. R. wrote: ...
Well, I reverted the procedure described in
Laicolasse:~ # cat /etc/crypttab # nvme0n1p2 Home # nvme0n1p3 Swap # nvme0n1p4, Main
#cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach #cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach #cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach
cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c none none cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 none none cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c none none
...
Bug?
dracut explicitly skips /etc/crypttab entries with valid third field (which refers to the existing key file on disk). There is no explanation, why. So, dracut does not find any swap device and skips "resume" module.
Why it does it for swaps only I do not know. Otherwise it is happy to actually unlock this device in initrd.
So yes, it does sound like a bug. It should either completely skip this device or fully configure it.
Sorry, what do you mean by fully configure it? When I had cr-auto-3 UUID=253d3fd9-7f53-465a-85f... /.root.key x-initrd.attach cr-auto-2 UUID=d153e878-b32c-4a14-856... /.root.key x-initrd.attach cr-auto-1 UUID=43662ac8-d98d-4b1a-a48... /.root.key x-initrd.attach then I only had to enter the password once on boot (on grub prompt for it), swap and all was unlocked, but machine would fail to restore from hibernation. AFAIR, lsinitrd /boot/initrd-5.14.21-150500.55.19-default /etc/crypttab did show the correct contents of the file, they looked complete. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))