Bug 746460
| Summary: | Grub2 "No such device:" error on Raid1 /boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | xaphir |
| Component: | grub2 | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | agk, amk, dennis, dledford, Jes.Sorensen, mads, marmalodak, mishu, pavel.lisy, pjones, vserbine |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-01 11:32:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
xaphir
2011-10-16 09:34:22 UTC
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. |