On Fri, 2005-04-15 at 15:05 -0500, John Morris wrote:
> On Thu, 2005-04-14 at 22:16, Chris Adams wrote:
>
> > No, you install GRUB on real disk devices, not software RAID partitions.
> > If /dev/md0 is your /boot and is on /dev/hda1 and /dev/hdb1 (and you
> > want to install to the MBR), do:
>
> Ok, while all of this Grub wizardry is assembled here, I have a
> question. Can you install grub in a partition instead of the MBR once
> RAID gets involved?
You can do it manually with the grub shell, but I didn't add support for
using grub-install to install the boot sector onto a partition when
you've got /boot on a RAID mirror.
I tend think this is something that's not really generally useful, but I
could probably be convinced that support is worth adding, if you have
some pretty good reasoning or maybe a patch ;)
> I have tried several times and failed, having trashed partitions and
> scrambled for rescue CDs many times in the attempts.
>
> Example:
>
> Assume a pair of plain IDE drives as hda and hdb.
>
> I have two different installs on the drives so only one can claim
> the MBR, thus:
>
> hda1/hdb1 = md0 / for the primary install
> hda2/hdb2 = md1 swapspace
> hda4/hdb4 = md2 /1 secondary install, reimages the primary, etc.
Really you're dual booting here; they just both happen to be Linux. (not
that there's anything wrong with that, I just want to be clear)
> The preferred method, and what I used to use on workstations in my
> primary location that aren't using RAID1, is to have the Grub in the MBR
> kick off hda4 and the default option will chain boot hda1 which has a
> version of grub which will boot hda1 and the normal environment. If it
> is horked up though, you simply hit the up arrow and pick "automated
> recovery" and it boots hda4, which blows away hda1, reloads it and then
> boots back into the main install.
*nod*, NCSU used to do the same thing essentially by putting the pxeboot
vmlinuz and initrd on a small partition and having a grub.conf entry
pointed at them.
> Didn't work once I started using RAID for the remote locations.
Er... "remote locations"?
> Now I have a sorty twitchy script on the recovery partition that
> pulls in the right stanza for the primary partition's kernel and
> stuffs it into it's copy of grub.conf.
Yeah, that sounds like something I'd want rid of, too. But why do you
need the hdX4 install to load the hdX1 instlal's kernel?
I see what you're trying to accomplish... but why not just put an entry
to boot the hdX4 install in the grub.conf on hdX1 ?
After all, you've already _got_ the bootloader there twice -- hda and
hdb -- and you shouldn't be reinstalling the bootblock very often. I'll
admit it's a little more complex if you want to update the hdX4
install's kernel, but from the sound of things this is really just a
really beefy rescue image, so e.g. security updates aren't particularly
important.
And sure, that means if hda's boot sector gets broken, you'll probably
have to physically swap the drives to boot it (so the old hdb is 0x80),
unless your bios allows you to do something equivalent. If it does,
then that's pretty trivial -- it's just a different menu.
I also tend to think a simpler solution (even if raid booting on
partitions were available) would be to pxeboot your recovery image.
> I suspect this knowledge might also be useful for Windows victims
> since it really wants to own the MBR for itself and has a nasty habit
> of reclaiming it without advance notice.
My thoughts so far have really been that RAID and dual booting together
are a case of "this only happens in the testlab".
--
Peter