Will FC3 grub DTRT wrt installation on software RAID-1 boot arrays

[Yusuf Goolamabbas]

Hi, I haven't tested FC3test as yet and wanted to ask if grub in FC3
would do the right thing when installing on a software raid-1 boot array
(ie, that it would write to the MBR on both disks) so if there was a
disk failure, the machine would still come up. Currently in FC1/FC2, if
you install on software raid-1 array and then remove the first disk, the
system won't boot up since there is no boot information on the MBR of
the 2nd disk. lilo would do the right thing but since that's being
deprecated. I don't know if Grub is capable of this task

An engineer from Dell has provided a document which gives a workaround
for this

http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/014331.html

Regards, Yusuf

[Alexandre Oliva]

On Sep 10, 2004, Yusuf Goolamabbas <yusufg(a)outblaze.com&gt; wrote:

>  Hi, I haven't tested FC3test as yet and wanted to ask if grub in
> FC3
>  would do the right thing when installing on a software raid-1 boot array
>  (ie, that it would write to the MBR on both disks) so if there was a
>  disk failure, the machine would still come up. 
The right thing depends on your BIOS and on the disk failure mode.

Consider, for example, that you have two disks, 0x80 and 0x81.  If you
naively install boot information on both disks' boot records such that
it looks for the boot partition in the disk itself, if you remove disk
0x80, disk 0x81 may not boot because it becomes 0x80.  OTOH, if you
replace disk 0x80, the BIOS will likely try to boot from it, and
fail.  If it fails over to the other disk, or if you change the BIOS
settings so as to boot from this other disk, then it might be
renumbered to 0x80, or it might not.  You can't have it work both
ways, unfortunately.

Then consider more interesting scenarios like multiple disks and you
may realize that, when lilo claims to be safe for raid 1, it's only
for a some failure scenarios, and within certain BIOS behaviors.

>  I don't know if Grub is capable of this task 
It is, but you have to do it yourself, implying what kind of failure
scenarios you're trying to prepare for.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva(a){lsd.ic.unicamp.br, gnu.org}

[Doncho N. Gunchev]

On 2004 09 10 (Friday) 09:14, Alexandre Oliva wrote:
>  On Sep 10, 2004, Yusuf Goolamabbas <yusufg(a)outblaze.com&gt;
> wrote:
>  
>  > Hi, I haven't tested FC3test as yet and wanted to ask if grub in FC3
>  > would do the right thing when installing on a software raid-1 boot array
>  > (ie, that it would write to the MBR on both disks) so if there was a
>  > disk failure, the machine would still come up.
>  
>  The right thing depends on your BIOS and on the disk failure mode.
>  
>  Consider, for example, that you have two disks, 0x80 and 0x81.  If you
>  naively install boot information on both disks' boot records such that
>  it looks for the boot partition in the disk itself, if you remove disk
>  0x80, disk 0x81 may not boot because it becomes 0x80.  OTOH, if you
>  replace disk 0x80, the BIOS will likely try to boot from it, and
>  fail.  If it fails over to the other disk, or if you change the BIOS
>  settings so as to boot from this other disk, then it might be
>  renumbered to 0x80, or it might not.  You can't have it work both
>  ways, unfortunately.
>  
>  Then consider more interesting scenarios like multiple disks and you
>  may realize that, when lilo claims to be safe for raid 1, it's only
>  for a some failure scenarios, and within certain BIOS behaviors.
>  
>  > I don't know if Grub is capable of this task
>  
>  It is, but you have to do it yourself, implying what kind of failure
>  scenarios you're trying to prepare for.
>  
    I have a Pentium 4 3000E and EPox EP-4PCAI with three Seagate
ST3160023A disks. I'm testing it with software raid1 and raid5 to
see how it works. I use (waiting for additional IDE controller):
--- cut ---
# grub
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/hdb
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/hdc
grub> root (hd0,0)
grub> setup (hd0)
--- cut ---
    When I remove any of the disks (or swap them randomly) it boots
without problems (even changing hdc to hdd). My setup is:
--- cut ---
# cat /proc/mdstat
Personalities : [raid1] [raid5]
md1 : active raid5 hda2[0] hdb2[1] hdc2[2]
      312046080 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]
md0 : active raid1 hda1[0] hdb1[1] hdc1[2]
      264960 blocks [3/3] [UUU]
-- cut ---
    md0 is /boot and everything else is on md1 (LVM). I don't know if
BIOS moves the first available disk to 0x80, but GRUB loads from any
disk (even if I connect hdc only). I'll try this with more machines
when I have time to.

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79

[Alexandre Oliva]

On Sep 10, 2004, "Doncho N. Gunchev" <mr700(a)globalnet.bg&gt; wrote:

>      When I remove any of the disks (or swap them randomly) it boots
>  without problems (even changing hdc to hdd). 
Right.  Now try to get the first disk to fail in such a way that it
remains visible to the BIOS but it no longer works, or no longer
serves the boot sector correctly, and see how that goes.  That's the
kind of scenario you might be willing to protect against, right?
Unfortunately, in this case, it won't renumber the disks, and the
system won't boot up.

>      md0 is /boot and everything else is on md1 (LVM). I don't
> know if
>  BIOS moves the first available disk to 0x80 
It does.  This is exactly what you're tell grub when you change the
device mapping.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva(a){lsd.ic.unicamp.br, gnu.org}