Description of problem: On a minimal install of F16 Beta to a raid installation, grub cannot boot the raid1 /boot partition, giving a "No such device:" id number and then dumping out to a rescue prompt. Steps to Reproduce: 1. Wipe two drives with dd if=/dev/zero 2. Partition the drives as extended type 85 partitions 3. Set up a 256 meg sdx5 logical partition with identical sectors on both drives 4. Set both sdx5 partitions for type fd 5. Start the F16 Beta netinstall CD and set the partitions as software raid 6. Attempt to use those partitions as the /boot partition in a raid1 array Actual results: Grub2 fails to boot probably due to an mdadm initialization problem
This looks exactly like 743273 which I reported earlier. *** This bug has been marked as a duplicate of bug 743273 ***
I can confirm this bug on pure software raid1. It is not dependant on IMSM raid device. It is problem of anaconda or grub2-install, see bug BZ 750794
I have retested this under RC5 with a new set of conditions: Steps to Reproduce: 1. Wipe two drives with dd if=/dev/zero 2. Partition the drives using gdisk and with a 1 meg ef02 Boot partition 3. Set up a 256 meg GPT primary partition with identical sectors on both drives 4. In gdisk, set both 256 meg GPT partitions for type FD00 5. Start the F16 RC5 netinstall CD and set the partitions as software raid 6. Attempt to use those partitions as the /boot partition in a raid1 array Results: Grub2 fails to boot, dumps you out to a rescue prompt just as before. So with the latest partitioning scheme using GPT, no difference even with RC5.
Ok reading over this again, it looks like a grub problem, not an mdadm bug, so reassigning to the right component for it to get some attention.
There has been several reports of grub2 failing to detect complex disk setups properly when launched from anaconda. The system will fail to boot, but if the same grub2 commands are run from some kind of rescue mode they will generate a working setup. That indicates some kind of problem outside grub2.
Mads, In fact that is exactly what I reported on 2011-10-17 in bug 743273; my brief report on fixing with system rescue cd is there. However, there does seem to be something going on with the module that runs floppy drives. At one point, doing rmmod on that allowed the install to continue successfully. That was back during the first betas tho and I have not attempted to replicate the problem since.
The problem is that device.map as generated by anaconda contains a line that claims that any mdX is a fakeraid. AFAIK it was ixed in latest anaconda but you need to delete stale /boot/grub/device.map yourself
Yes, this has been fixed in f17 where anaconda will be less eager to create device.map entries ... and create it correctly when it does. f17 do still use beta4 which predates the improved handling of invalid device.map entries. Analysis of this issue back then was made difficult by the problem only showing up while installing and not being able to reproduce it later.
Special handling os invalid fedora entries patch won't help as the entry in question here is valid, it's just wrong.