Bug 51910 - anaconda assumes /dev/md0 for software raid
anaconda assumes /dev/md0 for software raid
Status: CLOSED WORKSFORME
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda (Show other bugs)
roswell
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-16 14:51 EDT by Jim Wright
Modified: 2007-04-18 12:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-05 15:46:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim Wright 2001-08-16 14:51:51 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):


How reproducible:
Always

Steps to Reproduce:
get anaconda to create software raid sets, but with none assigned to
/dev/md0

Additional info:
Comment 1 Glen Foster 2001-08-17 15:15:41 EDT
We (Red Hat) should really try to fix this before next release.
Comment 2 Matt Wilson 2001-08-20 10:04:15 EDT
did you go back to the disk partitioning screen after you defined your
partitions and hit Next?
Comment 3 Matt Wilson 2001-08-20 10:06:38 EDT
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?
Comment 4 Jim Wright 2001-08-20 14:04:35 EDT
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.
Comment 5 Matt Wilson 2001-09-05 15:46:22 EDT
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.
Comment 6 Jim Wright 2001-09-05 19:50:42 EDT
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.
Comment 7 Matt Wilson 2001-09-05 20:02:49 EDT
I verified that /dev/md10 was up and running before the initrd exited, so this
would work as the root filesystem as well.

Note You need to log in before you can comment on or make changes to this bug.