Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 234674 - /dev/md? not found after creating raid-1 partition in install
Summary: /dev/md? not found after creating raid-1 partition in install
Alias: None
Product: Fedora
Classification: Fedora
Component: raidtools
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-31 01:24 UTC by Larry Matter
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-02 16:54:48 UTC
Type: ---

Attachments (Terms of Use)

Description Larry Matter 2007-03-31 01:24:15 UTC
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:

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-31 02:57:37 UTC
possibly related:

Comment 2 Doug Ledford 2007-03-31 13:15:38 UTC
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 17:42:50 UTC
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 16:35:18 UTC
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 16:54:48 UTC
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.