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):
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
new installation fails to boot, drops into single-user mode with failure
udev should create the /dev/md? nodes
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.
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.
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.
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.