RE: grub failure to update MBR (using RAID and LVM)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Great, thanks!  

I used dd as you described, and everything looked pretty normal, but I went a step further.  I had my rescue cd handy so I went ahead and blasted away my MBR like this:  dd if=/dev/zero of=/dev/hda bs=512 count=1.  I did the same for the other two.  I rebooted to check for the expected behavior, the system hang at the end of POST, as it should without any MBR.  So, I went in with the cd, chrooted, and ran grub again.  I rebooted, and much to my surprise, the old menu was back again!  I turned my attention to my RAID and discovered that my drive designations were all wrong.  /dev/hda was a hot spare instead of /dev/hdc, and /dev/hda had old data on it.

I simply used "root (hd1,0)" instead of "root (hd0,0)" and ran "setup (hd0)", "setup (hd1)", and "setup (hd2)", one right after the other.  

Also, I performed a series of simulated failures and would like to offer advice below on setting up RAID for use with GRUB for anyone interested:

1) Set your BIOS to attempt to boot all drives before giving up
2) Make a separate entry in your grub.conf for each drive in the mirror, so that when one fails, you can fall back to the good drive by selecting it on the menu.  For example:

default=0
timeout=10
#splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core Primary (2.6.10-1.766_FC3)
        root (hd0,0)
        kernel /vmlinuz-2.6.10-1.766_FC3 ro root=/dev/Volume00/root
        initrd /initrd-2.6.10-1.766_FC3.img
title Fedora Core Secondary (2.6.10-1.766_FC3)
        root (hd1,0)
        kernel /vmlinuz-2.6.10-1.766_FC3 ro root=/dev/Volume00/root
        initrd /initrd-2.6.10-1.766_FC3.img

3) Notice that I commented out the pretty splash image.  If hd0 fails, where will the spash image come from?
4) Manually install grub onto both MBRs.  Linux RAID won't duplicate the master boot record (at least it doesn't for me).
5) If you have a partitioned hot spare, you might want to put a copy of grub on it too. Just in case one does fail, you will be able to boot via that one as well.

Granted, there is a chance that the drive replacement will hang up the boot process, but at least you won't have to go through using the rescue cd, and at most you will need to change your boot order in your BIOS setup to get around it.

I am also working on some automation scripts to automate the RAID rebuild process after the failed drive is pulled out.  If I can ever get them to work I'll post them for anyone who likes the idea of performing a dummy-proof drive swap (other than making sure that the drive that is being pulled is the right one!).


--

Shawn 

 
On Thursday, February 17, 2005 5:23 PM, Paul Pianta wrote:
>
>

<snip>

>
>Hey Shawn 
>
>I have run into this problem b4 too. Check out 'Step 25' at 
>this link ...
>
>http://togami.com/~warren/guides/remoteraidcrazies/
>
>You can also verify if grub is 'really' installed on your 
>disks by doing a 'dd if=/dev/hda bs=512 count=1' on each disk.
>
>If grub is really installed you should see something like this - 
>
>---snip---
>
>[root@trinity root]# dd if=/dev/hda bs=512 count=1
> ÐØ | 8u
> u |tAÊ |1ØÐ @|<t y} tTAU ZRrIUuCA|  t7fL| fD|  f pf1 DfD
>B rp s
> | f@fD1   @  ffD|f1 4T
>f1 tT
>D
> L ;}<T
> Ñl
>Zt
>p Û r*ÃH|` 1a&B|}  }  } }  GRUB GeomHard DiskRead Error <u  v? 
>?/  ~} KK4 LL#/-U1+0 records in
>1+0 records out


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux