FS#78661 - [util-linux] 2.39-4 breaks boot when using mdraid and LUKS rootfs
Attached to Project:
Arch Linux
Opened by Giulio Picierro (kudraw) - Wednesday, 31 May 2023, 07:44 GMT
Last edited by Toolybird (Toolybird) - Friday, 09 June 2023, 20:55 GMT
Opened by Giulio Picierro (kudraw) - Wednesday, 31 May 2023, 07:44 GMT
Last edited by Toolybird (Toolybird) - Friday, 09 June 2023, 20:55 GMT
|
Details
Description:
In a configuration with the root partition in RAID-1 (mdraid) and encrypted with LUKS, upgrading to util-linux 2.39-4 breaks the boot, resulting in entering systemd Emergency Mode. It looks like it doesn't find/mount the RAID device (and as such obviously it does not prompt for the LUKS password at boot). Downgrading to the previous release of util-linux and util-linux-libs 2.38.1-4 solve the problem. Additional info: * I use an Unified Kernel Image (uki), signed for UEFI Secure Boot (I think this is irrelevant for the specific issue). * /etc/mkinitcpio.conf contains the following: HOOKS=(base systemd autodetect modconf keyboard sd-vconsole block mdadm_udev sd-encrypt filesystems fsck) * /etc/kernel/cmdline contains the following: root=/dev/mapper/crypto rw loglevel=3 audit=0 * /etc/crypttab.initramfs has the following line: crypto /dev/md0 none * /etc/mdadm.conf contains: DEVICE partitions ARRAY /dev/md/hostname:0 metadata=1.2 name=hostname UUID=<redacted> (hostname and UUID redacted, not relevant) I've also tried to specify the proper UUID in the other files, but nothing has changed. The only solution was the downgrade to 2.38.1-4. Thank you in advance! Steps to reproduce: * Using a root filesystem on RAID+LUKS * Upgrade to util-linux and util-linux-libs 2.39-4 * Generate an initramfs with: HOOKS=(base systemd autodetect modconf keyboard sd-vconsole block mdadm_udev sd-encrypt filesystems fsck) * Reboot |
This task depends upon
Closed by Toolybird (Toolybird)
Friday, 09 June 2023, 20:55 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments in upstream ticket
Friday, 09 June 2023, 20:55 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments in upstream ticket
[1] https://github.com/util-linux/util-linux/issues/2271
thanks for your reply, very helpful.
It looks like *very* related.
blkid (util-linux 2.38.1-4) reports the two partitions composing the RAID as TYPE="linux_raid_member",
however an hexdump on the first device shows that the first 4 bytes are "LUKS".
Effectively, I converted this partition from LUKS only to RAID+LUKS by using the trick that the RAID header is at 4K offset.
However I didn't erase the LUKS header.
Unforunately I cannot test right now, but as soon as possible I will attempt to clear the header, make the upgrade to 2.39-4 again and see if this solve the issue.
Thank you!