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:
possibly related: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225468
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.