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

Re: PATCH: allow installing grub on the MBR if /boot is on mdraid.

On Sun, Nov 30, 2008 at 8:49 AM, Hans de Goede <hdegoede redhat com> wrote:
> Jeremy Katz wrote:
>> On Wed, 2008-11-26 at 12:06 +0100, Hans de Goede wrote:
>>> This patch removes a special case when /boot (or / without a separate
>>> /boot) is on mdraid. For some reason we only allow installing grub to the
>>> mdX device then instead of allowing both the mbr of the 1st disk and the
>>> device holding /boot.
>>> I've searched through the anaconda history and this special handling of
>>> mdraid /boot has been there since before Feb. 2002, it was inherited from
>>> before booty was introduced and it does not seem to make sense. Either we
>>> cannot have /boot on mdraid at all (in all cases except for raid1) or we can
>>> have /boot on dmraid (in case of raid1) and then it does not matter if the
>>> bootstrap of grub starts on the mbr or on the first sector of a partition.
>> The reason we install to the mdX device is so that if your disk dies,
>> the bootloader install is mirrored[1] to both disks.  So while it is
>> technically possible to install to the mbr of the first disk, doing so
>> loses the redundancy of the RAID install.
> Well, that is pretty useless, this could be usefull when the first disk (as
> seen by the BIOS) dies, except that if 99% of the cases that happens the
> BIOS will still see the disk and thus still try to boot from it and fail.
Acutally, it is pretty useful, even though you have to go into the BIOS most
times as you say.  In our case we can get to our BIOS remotely (serial
console with BIOS that supports that), so we can change the boot order
and bring the system back up.

BIOS manufacturers supporting changing BIOS settings from a linux utility
(or at least documenting the configuation mapping of NVRAM) would be
a big step in the right direction, as one could detect a failed disk and
automatically tell the BIOS to boot from the other disk.  Even without
their help though you can get there by having two copies of the NVRAM
settings (cat /dev/nvram > nvram.bak, will do it).  One copy boots from
the first disk the other from the second.  Once you have this, on detection
of a failure you just blow in the NVRAM setting that boots from
the second disk.  This is of course is a hack, but it works.

As it is now in our %post script we end up blowing in an MBR on the
second disk...but we are always excited about deleting code.


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