Subtle misconfiguration in initramfs after dnf upgrade; boot breaks under some circumstances

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I recently installed a fresh minimal copy of Fedora 34 using Anaconda and this fairly simple Kickstart file (see below). To save you some reading, the Kickstart file creates 3 software RAID1 arrays (/, /boot, and swap) and installs Fedora 34 on top.

When Anaconda completes, I'm presented with a working system running on top of a bootable software RAID1. So long as I continue to use the initramfs that was created for me by the installer, I can unplug a drive (thus degrading the RAID1 array), and continue to still boot the system.

But, as soon as I run dnf upgrade and pull in a new kernel (updating 5.11 to 5.13), the new initramfs that gets generated will lose the above functionality (booting off a degraded array). The system will still boot when all RAID1 members are present, but as soon as a single member of the RAID1 is lost, I get dropped into a dracut emergency shell and then need to manually turn all the inactive arrays active via a series of mdadm --run /dev/md[X] and mdadm --readwrite /dev/md[X] commands.

Any idea why Anaconda+Kickstart can create a working initramfs that supports booting off of a degraded software RAID1 array, but dracut can't when it's automatically invoked by dnf update?

For additional information see:
Kickstart file:  https://gist.github.com/zacharyfreeman70/ead4c8a9d2fec58753d7c295f39cfc00
GitHub issue: https://github.com/dracutdevs/dracut/issues/1593
Reddit post: https://old.reddit.com/r/Fedora/comments/pdqw3v/initramfs_built_incorrectly_after_dnf_upgrade/




[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux