Bug 746460 - Grub2 "No such device:" error on Raid1 /boot
Grub2 "No such device:" error on Raid1 /boot
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
16
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-16 05:34 EDT by xaphir
Modified: 2012-06-01 10:52 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-01 07:32:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description xaphir 2011-10-16 05:34:22 EDT
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
Comment 1 Jes Sorensen 2011-10-17 04:03:54 EDT
This looks exactly like 743273 which I reported earlier.

*** This bug has been marked as a duplicate of bug 743273 ***
Comment 2 Pavel Lisý 2011-11-02 07:52:03 EDT
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
Comment 3 xaphir 2011-11-04 16:42:11 EDT
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.
Comment 4 Jes Sorensen 2011-11-22 08:40:35 EST
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.
Comment 5 Mads Kiilerich 2011-11-22 15:07:04 EST
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.
Comment 6 xaphir 2011-11-29 04:58:56 EST
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.
Comment 7 Vladimir Serbinenko 2012-06-01 07:21:57 EDT
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
Comment 8 Mads Kiilerich 2012-06-01 07:32:23 EDT
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.
Comment 9 Vladimir Serbinenko 2012-06-01 10:52:38 EDT
Special handling os invalid fedora entries patch won't help as the entry in question here is valid, it's just wrong.

Note You need to log in before you can comment on or make changes to this bug.