Description of problem: mkinitrd detecting need for raid5 personality, but does not load raid456 module and thus the resulting initrd fails with kernel panic, not syncing since / cannot be found. Version-Release number of selected component (if applicable): mkinitrd-5.1.6-1 How reproducible: Every time. Steps to Reproduce: 1. yum update 2. reboot 3. kernel panic. Msg that raid5 personality not loaded is seen during initrd boot Actual results: kernel panic since / can't be found Expected results: Normal boot Additional info: This system has the root filesystem on LVM over software raid5. The problem has been around awhile, but only discovered when updating system from rawhide after not updating for over two months. Running mkinitrd -f -v without specifying raid456 module results is same bad img file as when using yum. File attached showing results. Note that need for raid5 is detected, but module raid456 is not loaded. Running mkinitrd -f -v --with=raid456 results in good img file that boots properly. File attached showing results. Previous version of mkinitrd also failed. Did not go back farther to see where the problem started.
Created attachment 134209 [details] mkinitrd -f -v without specifying any modules to load
Created attachment 134210 [details] mkinitrd -f -v --with=raid456
The patch in bug 202559 fixes this as a side effect.
What in the world happened with this bug. It was a RHEL5 bug with a beta blocker status requested, but now it's a FC bug which has been closed out. Is this still an issue with RHEL5? More importantly, is this an issue which needs to be resolved for beta? If so, we really need a RHEL version of the bug to track things.
OK, ignore comment 5. I see this was cloned to another bug for RHEL.
I am seeing this bug for mkinitrd-5.0.32-2 when updating FC5 to kernel 2.6.18-1.2200.fc5smp. Reruning mkinitrd under an older FC5 kernel and using --with=raid456 solves the problem. Should this bug be reopened or a new bug entered?
Open a new one, please.
found one already opened: bug 211030.