Bug 234674 - /dev/md? not found after creating raid-1 partition in install
/dev/md? not found after creating raid-1 partition in install
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: raidtools (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-30 21:24 EDT by Larry Matter
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-02 12:54:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Larry Matter 2007-03-30 21:24:15 EDT
Description of problem:
after creating raid-1 "partition" during install, fc fails to boot:
fsck.ext3: /dev/md0 not found (or something like that)
drops into single-user mode.

Version-Release number of selected component (if applicable):


How reproducible:
everytime

Steps to Reproduce:
1. during install, select custom partitioning, create a raid-1 device
2. select a mount point for the partition, and format it
3. reboot after successful install
  
Actual results:
new installation fails to boot, drops into single-user mode with failure
described above.


Expected results:
udev should create the /dev/md? nodes

Additional info:
Comment 1 Larry Matter 2007-03-30 22:57:37 EDT
possibly related:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225468
Comment 2 Doug Ledford 2007-03-31 09:15:38 EDT
The component raidtools is incorrect.  Raidtools was deprecated *long* ago,
mdadm is the current raid management software in use.  However, mdadm is only
the tool used to start raid devices, mkinitrd and initscripts control the
running of mdadm on boot up, and anaconda controls the creation of the
mdadm.conf file during installation.  So, in order to assign this to the right
component, I need to ascertain whether the problem is one of:

1) mdadm itself failing to find/start a valid array
2) mkinitrd failing to call mdadm properly
3) initscripts failing to call mdadm properly
4) mdadm.conf file having bogus information
or 5) something else.

So, can you put the contents of your /etc/fstab and /etc/mdadm.conf files on
this bug report, as well as the output from fdisk -l on one of your hard disks.
   Having that information should help out here.
Comment 3 Larry Matter 2007-03-31 13:42:50 EDT
It will be some time until I can attempt a reinstall.  I did not check the
mdadm.conf but /etc/fstab had a normal mount entry for /dev/md0.  /dev/md0 was
not present however.

I did another install (before your comment), left the /dev/md0 device in tact,
but did not provide a mount point.  After a successful install I manually added
the entry in /etc/fstab (and formated /dev/md0) and it rebooted fine.
Comment 4 Matthew Miller 2007-04-10 12:35:18 EDT
Fedora 7 test bugs should be filed against "devel", not against test1/2/3. This
isn't obvious, I know. Moving this report so it isn't lost.

This is a bulk message -- I apologize if this was actually meant to be targeted
against a different release. If so, please fix or let me know. Thanks.
Comment 5 Doug Ledford 2007-07-02 12:54:48 EDT
This problem should have been resolved prior to the final f7 release.  From the
description, this sounds like the problem you have when the md device in
question is not part of your / filesystem, which means the mkinitrd doesn't
attempt to start it and instead it has the /etc/rc.d/rc.sysinit script start the
array.  There was a bug in the rc.sysinit script that was resolved prior to
final f7 release that kept these non / arrays from being started.  If I'm
incorrect and the problem still persists, please reopen this report.

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