From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.6-xfs i686) Description of problem: I proceeded with the install with root as /dev/md10 and /boot as /dev/md11. After the install, my system was unbootable. Investigating in the initrd, I found that it did a "raidstart /dev/md0". But /dev/md0 is not being used, so the raid system didn't start and I had no filesystems. I fixed the initrd problem above, and rebooted. Still didn't work. The /dev directory in the initrd only had /dev/md0. When it tried to do a "raidstart /dev/md10" it failed with no such device. Fixed that, and rebooted. Finally got the system up and running. I say anaconda but I really mean the interaction between anaconda and whatever is creating the initird. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: get anaconda to create software raid sets, but with none assigned to /dev/md0 Additional info:
We (Red Hat) should really try to fix this before next release.
did you go back to the disk partitioning screen after you defined your partitions and hit Next?
very odd, we're using the autostart ioctl, which just needs a md device major. The minor number shouldn't matter at all. But you say that copying the devnode for md10 and changing the line in the initrd made it work?
This bugzilla is derived from a longer post to the beta list. Sorry if context was lost as I split that message into several different reports. Subject: [Bug 51907] New - disk druid inserts rather than appends software raid sets Subject: [Bug 51908] New - anaconda discards previous md defs and assigns new Subject: [Bug 51910] New - anaconda assumes /dev/md0 for software raid Subject: [Bug 51911] New - problems creating software raid10 First boot - no root filesystem, kernel panic use "linux rescue", diddle /boot/initrd* by mknod /dev/md10 Second boot - no root filesystem, kernel panic use "linux rescue", diddle /boot/initrd* by editting linuxrc to reference /dev/md10 Third boot - worked.
I installed a machine with a /dev/md0, then booted into it. I blew away the /dev/md0 and made it /dev/md10. This means that there is no /dev/md0 on the system. I rebooted and everything worked.
I think the difference between what you did and what I did was that I had this as the root filesystem. So getting modules loaded and running from the initrd was critical for me, while (and I'm reading between the lines of what you wrote) it looks like you had a running system to work with. Actually, this is now no longer a problem because by fixing [Bug 51907] and [Bug 51908] this situation won't occur. So leave as closed.
I verified that /dev/md10 was up and running before the initrd exited, so this would work as the root filesystem as well.