Red Hat Bugzilla – Bug 51910
anaconda assumes /dev/md0 for software raid
Last modified: 2007-04-18 12:35:59 EDT
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):
Steps to Reproduce:
get anaconda to create software raid sets, but with none assigned to
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
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
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.