Bug 466375 - grub doesn't correctly install MBR into /dev/mdX software raid array
grub doesn't correctly install MBR into /dev/mdX software raid array
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-09 18:07 EDT by Ugo Viti
Modified: 2009-08-10 04:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-10 04:48:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ugo Viti 2008-10-09 18:07:03 EDT
Description of problem:
in every Fedora release I always seen that grub doesn't install correctly the MBR into software raid1 /dev/mdX.

Let's me explain:

for example consider the following simple scenario where installing Fedora:

/dev/sda = first sata HD
/dev/sdb = second sata HD

/dev/sda1 + /dev/sdb1 = /dev/md0 (raid1)
/dev/sda2 + /dev/sdb2 = /dev/md1 (raid1)
/dev/sda3 + /dev/sdb3 = /dev/md2 (raid1)

/dev/md0 mounted as /
/dev/md1 mounted as /var
/dev/md2 used as swap

I make a raid1 for swap also.

let's grub select the boot device automatically (it autoprobe /dev/md0 of course) where install the MBR.

Finish the installation and reboot.

cat /proc/mdstat

first test:
when the synchronization is over, shut down the system, disconnect the /dev/sdb from the sata port, power on the system: the system boot correctly (great!).
cat /proc/mdstat show a degraded array (right, we have just removed one drive from the array)

second test:
reconnect the sdb to the sata port, boot the system and re-add the sdb1, sdb2 sdb3 to the corresponding array, wait resync finish, shut down the system and this time remove the sda. poweron, the screen remain black with "GRUB" text into upper left.

To solve this annoying problem I use the following procedure (every time I install a new system with raid1 software)

after the first successful boot, login as root, run the 'grub' command and insert into grub shell:

device (hd0) /dev/sda
root   (hd0,0)
setup  (hd0)

device (hd1) /dev/sdb
root   (hd1,0)
setup  (hd1)

after installing grub into /dev/sda and /dev/sdb, you can boot the system even if the /dev/sda (first drive) completely crash.

I don't know how anaconda install grub into a RAID1 arrays, but surely doesn't install it very well, because from a default installed Fedora, if the first HD crash, the system become unboottable.

Version-Release number of selected component (if applicable):
Last test made when installing Fedora 9: grub-0.97-33.fc9

How reproducible:
install fedora into raid1 software and remove the first hd, the system doesn't boot any more.

Steps to Reproduce:
1. install fedora into a software raid1 array
2. install grub using default proposed options
3. wait finish arrays resync, shut down and remove the first hard disk (tipically /dev/sda) 
Actual results:
the system doesn't boot

Expected results:
boot the system from the second HD (of course the bios must be configured to try others HD before hangup the boot process)

Additional info:
Should be great if this problem will be addressed before the upcoming Fedora 10.

Best Regards
Comment 1 Bug Zapper 2008-11-25 22:43:51 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 2 Hans de Goede 2009-08-10 04:48:34 EDT
This has been fixed in rawhide for a couple of anaconda release now, closing.

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