Bug 114690 - grub-install won't install to RAID 1
grub-install won't install to RAID 1
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: grub (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
: Patch
: grubraid 122804 138572 147411 153060 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-31 10:35 EST by Milan Kerslager
Modified: 2007-11-30 17:07 EST (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-05 11:06:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to add support for md devices to grub-install. (6.53 KB, patch)
2004-08-25 17:56 EDT, David Knierim
no flags Details | Diff

  None (edit)
Description Milan Kerslager 2004-01-31 10:35:23 EST
When RAID1 is used for mirroring partitions (by Anaconda), grub is 
unable to install itself to MBR.

I tried grub-install with each of /dev/md0, /dev/md1, /dev/sda, 
and /dev/sdb. Each reported that /dev/md? does not have any 
corresponding BIOS drive, and failed to overwrite the MBR. I tryed to 
modify /boot/grub/device.map with no luck.

LILO is able to install itself correctly.

See old bug #55484 for more info (used to be filled for RH 7.2, 8.0 
and 9).

# lsraid -p
[dev   9,   0] /dev/md0  CFCC137A.A19C3EF8.7AD2F777.8F6C7210 online
[dev  22,   1] /dev/hda1 CFCC137A.A19C3EF8.7AD2F777.8F6C7210 good
[dev  22,  65] /dev/hdb1 CFCC137A.A19C3EF8.7AD2F777.8F6C7210 good

md0 is for root FS (/).
Comment 1 Milan Kerslager 2004-01-31 10:40:41 EST
*** Bug 55484 has been marked as a duplicate of this bug. ***
Comment 2 Steve Bonds 2004-07-14 04:02:00 EDT
This bug gets me with each new install.  You'd think I'd learn after
hitting it so many times.  Adding myself to the CC: list just in case
the day comes when frozen pigs fly out of hell and RedHat fixes this.
Comment 3 David Knierim 2004-08-25 17:56:52 EDT
Created attachment 103100 [details]
Patch to add support for md devices to grub-install.

Here's a patch I worked out to make grub-install work against md devices.   I
don't understand grub as well as I like, but it appears to work.
Comment 4 Konstantin Olchanski 2004-10-09 15:56:24 EDT
I see the same problem with Fedora-2. "grub-install /dev/hda" and
"/dev/md0" reports "/dev/hda does not have a corresponding BIOS
device". How the heck does the installer make it work during the
initial installation?!?

BTW, the error message is incorrect. *Of course* /dev/hda has a
corresponding BIOS device hd(0,0). The error message should say "I am
too stupid to figure out the BIOS device for blah..." and
"grub-install" should have an option where I can specify which BIOS
disk I want to use.

K.O.
 
Comment 5 Lorenzo Musizza 2004-11-25 11:21:33 EST
I had this problem today with my Fedora 3 box (RAID1 setup), after I
installed some official updates. I rebooted and I got stuck to the
GRUB string on the screen. I booted into rescue-cd, grub-install was a
no-go (not have a corresponding BIOS device). I was successful only by
manually giving commands to the grub shell.
Since this is a continuation of a previous bug, I think this is a very
very long standing bug (since RH 7.x or something) that really deserve
fixing. 
Comment 6 Boris Mironov 2004-11-29 09:39:38 EST
Hello,

May be this will help to solve the problem (at least it worked for me
on Fedora 3):

http://www.linuxsa.org.au/mailing-list/2003-07/1270.html

Good luck,
Boris
Comment 7 Boris Mironov 2004-11-29 09:47:34 EST
Hello,

Did not mention my exact way...

1) Install Fedora 3 on RAID 1 (consists of 2 IDE HDDs). Each drive has
2 partitions (data, swap).

2) First reboot will stuck (eg., no boot device).

3) Boot from first CD of Fedora 3 as 'linux rescue'.

4) From shell start 'grub'

5) From grub execute the following:
root (hd0,0)
setup (hd0)
root (hd1,0)
setup (hd1)

This is it. The rest is up to you.


Probably these 4 commands (or some better work around) could be
implemented in anaconda, especially when user installs Linux on
software RAID.


Good luck,
Boris
Comment 9 Peter Jones 2005-01-05 11:06:05 EST
0.95-6 should fix this.
Comment 10 Peter Jones 2005-01-25 10:34:28 EST
*** Bug 138572 has been marked as a duplicate of this bug. ***
Comment 11 Gary Benson 2005-02-04 05:34:43 EST
I'm running software raid, and I've not seen the error on RHL 7.3,
8.0, 9, and up until now FC3. I picked up a new kernel-smp over yum
the other day, however, and I got bitten by it this morning when I
tried to boot my box.

grub version is 0.95-3
Comment 12 Julien 2005-02-20 07:31:39 EST
Hello, 

Same problem but simplier fix :

Boot rescue mode

edit grub.conf and remove the comment on this line :
#boot=/dev/sda1

worked after for me.
Comment 13 Milan Kerslager 2005-02-21 07:14:43 EST
You will have only one disc with bootloader then. Repeat for each disc
in RAID-1 array or use manual procedure above.
Comment 14 Peter Jones 2005-03-01 13:26:38 EST
*** Bug 147411 has been marked as a duplicate of this bug. ***
Comment 15 Paul Moore 2005-03-04 08:24:43 EST
Also seems to happen with RHEL4
Comment 16 Peter Jones 2005-03-14 14:30:56 EST
*** Bug 122804 has been marked as a duplicate of this bug. ***
Comment 17 David Tonhofer 2005-03-31 11:51:48 EST
Definitely happens for Red Hat ES 4.0.

The interesting thing is the Anaconda installer. I software-mirrored the boot
partition, and the installer only gave the option to write the boot record
to the partition holding /boot, it said nothing about writing the MBR. 

I stupidly missed the hint and fumbled with the BIOS settings a long time.

Then I saw the light, un-RAIDed the boot partition and voilà: Anaconda gives
the possibility to write the MBR!

This bug should not be "closed". I will open a new bug for Red Hat ES 4.0 and 
reference this one.
Comment 18 Steve Bonds 2005-03-31 13:43:29 EST
Peter Jones said that "0.95-6 should fix this", but unfortunately both RHEL 4
and FC3 ship with 0.95-3.1.  This problem may well be fixed in 0.95-6, but we
can't tell since it doesn't seem to exist.

I agree that this bug shouldn't have been closed until the fix shipped.
Comment 19 Peter Jones 2005-04-01 11:39:36 EST
*** Bug 153060 has been marked as a duplicate of this bug. ***
Comment 22 David Tonhofer 2005-05-22 17:51:45 EDT
Additional comment:

Although I have managed to install RHEL 4.0, then bind the /dev/hde1 and
/dev/hdg1 partitions into /dev/md0 RAID 1 onto which /boot is then mounted,
the RAID fails on every boot (I more or less used Boris Mironov's idea, above).
More clearly:

At runtime, bliss: 

/dev/hde1  --+
             +---> /dev/md0 --> /boot
/dev/hdg1  --+

On boot, GRUB boots from /dev/hde1, then we find this in /var/log/dmsg:

md: considering hdg1 ...
md:  adding hdg1 ...
md: created md0
md: bind<hdg1>
md: running: <hdg1>
raid1: raid set md0 active with 1 out of 2 mirrors

After which /dev/md0 runs in degraded mode (awww what a letdown!):

/dev/hde1  
             +---> /dev/md0 --> /boot
/dev/hdg1  --+

mdadm --detail /dev/md0 shows:

    Number   Major   Minor   RaidDevice State
       0       0        0       -1      removed
       1      34        1        1      active sync   /dev/hdg1

I then have to re-create the array:

# mdadm /dev/md0 -a /dev/hde1

...So something blows the mirror away. It's not 'bad blocks', I have checked
with 'badblocks'. And using 'dd' and a little script, the only block
that differs is block 2, which is apparently part of the mountpoint metadata
(not sure). Maybe GRUB decides to tweak that, thus causing the mirror to
fall apart.

Conclusion: Even if installation of /boot to a RAID would work, it might
not actually work afterwards.


Comment 23 Manjeet Chaudhary 2005-07-14 05:54:23 EDT
I am using RHEL4.0 with kernel 2.6.9-667smp. installed on two SATA drives
configured as Sotware RAID1.
The problem i faced is similar to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138572#c0

I installed the OS properly and it was working fine. 

Description of problem:
I was formatting my 750GB Hardware RAID partition and in between system stuck at
last stage of inode creation.(unable to tell the error messages)
I did the hardware reset. And after that grub failed to load.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138572#c0 . 
It did not worked for me. Message : /dev/sda not found. 

I tried the trick by Julien 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114690#c12 . Again grub
failed to load.

Then tried the trick by Keith McDuffee
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484#c10
After reboot my machine is booting properly.
Comment 24 Manjeet Chaudhary 2005-07-14 06:00:56 EDT
I am using RHEL4.0 with kernel 2.6.9-667smp. installed on two SATA drives
configured as Sotware RAID1.
The problem i faced is similar to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138572#c0

I installed the OS properly and it was working fine. 

Description of problem:
I was formatting my 750GB Hardware RAID partition and in between system stuck at
last stage of inode creation.(unable to tell the error messages)
I did the hardware reset. And after that grub failed to load.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138572#c0 . 
It did not worked for me. Message : /dev/sda not found. 

I tried the trick by Julien 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114690#c12 . Again grub
failed to load.

Then tried the trick by Keith McDuffee
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484#c10
After reboot my machine is booting properly.
Comment 25 Jason Haar 2005-07-20 18:45:02 EDT
I am seeing the same thing under CentOS-4.1. Not exactly Redhat - but not
exactly not RHE either :-)

I have a /dev/md1 RAID-1 partition for "/" and no separate "/boot" partition.
Running "grub-install -no-floppy /dev/md1" gives me the "corresponding BIOS
device" error as above. This is with CentOS-4.1's grub-0.95-3.1.

This is on a MPTFUSION SCSI server with disks on /dev/sda and /dev/sdb - but I'm
sure this is purely a grub-vs-RAID issue as mdadm is totally happy with the
disks, and I have also repeated the same problem with an IDE-based install too. 

If I manually call grub and do:

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

It crashes (segfault) grub straight after entering the setup command. I also
waited until mdadm reported that it had synced the two disks before doing it
again - no difference.
Comment 26 Doncho N. Gunchev 2005-08-07 15:43:39 EDT
(In reply to comment #25)
...
> If I manually call grub and do:
> 
> device (hd0) /dev/sda
> root (hd0,0) 
> setup (hd0)
> 
> It crashes (segfault) grub straight after entering the setup command.
...
    Try booting an UP kernel and it should work (worked for me at least).
Comment 27 Egg 2005-09-07 09:19:50 EDT
I am also receiving this problem with centos (rhel) 4.0 and 4.1.

Two RAID 1 arrays from 4x80gb Seagate hdd's partitioned as:


DEVICE          START    END   SIZE      TYPE         MOUNT POINT
-----------------------------------------------------------------
VG VolGroup00                  152352M   VolGroup   
LV LogVol00                    150272M   ext3         /
LV LogVol01                      1984M   swap
/dev/sda
   sda1              1     13     101M   ext3         /boot
   sda2             14   9724   76277M   physical v
/dev/sdb
   sdb1              1   9724   76277M   physical v


The system hangs after installation at the grub propt (flashing underscore _).

Andy's fix was irrelavent as mtab and devices.map were already pointing to sda 
and sda1:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138572#c5
Comment 28 Sergey Svishchev 2006-01-24 03:57:58 EST
So, will hell freeze over anytime soon?  This bug is still here on RHEL3 U6 with
no update in sight.
Comment 29 David Tonhofer 2006-01-27 12:29:00 EST
Anyone who comes across this DISREGARD my comment #22 above. The mirror would
probably work (I'm currently simply not mirroring /boot) were it not for the
hardware. The machine this is running on just cannot be rebooted, it needs to
be powercycled or there will be problems with the first disk on reboot.
Comment 30 Jim 2006-08-16 09:51:46 EDT
August 16, 2006 - bug still exists. Exactly as described above. New 64bit 
install (for the millionth try). ide drive and sata2 x2 disks raid1. Trying to 
get the computer to boot after the install just stalls, and crashes at a GRUB 
message, which just say's "GRUB". Did every fix that can be found on the first 
200 results at google, to no avail.

Kind of useless having /boot on raid1 if the OS wont boot. Equally as useless 
is being forced to put /boot on a single drive when trying to avoid single 
points of failure on the server. 

SUSE10 64 bit installs easilly in 10 minutes, and boots right up. Looks like 
that's what the servers will be running.
Comment 31 David Tonhofer 2006-08-24 16:49:15 EDT
Just cross-referencing this, I guess its best to post to still open bugs ;-)

Hell hath still not frozen, pigs still taxiing on the runway. Tower control do
you copy?

Bug #191449 NEW install grub incorrect when /boot is a RAID1 device
Bug #170575 NEW grub fails on one of two sata disks of raid1 set during i...
Bug #163460 NEW Installation failed on RAID setup (GRUB error 15 and fail...
Bug #160563 NEW "grub-install /dev/md0" does not install on second disk i...
>> Bug #114690 CLOSED/RAWHIDE grub-install won't install to RAID 1

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