A Grub question

John Morris jmorris at beau.org
Fri Apr 15 22:47:36 UTC 2005


On Fri, 2005-04-15 at 15:54, Peter Jones wrote:

> 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 was doing it with an older (RHEL3) grub.  I'll try again with the
lastest, but I tried every invocation from the grub shell I could think
of and either got error messages or trashed RAID volumes.

> > Didn't work once I started using RAID for the remote locations.
> 
> Er... "remote locations"?

Local being in the building with me, where it is easier to just keep a
complete spare workstation ready to drop in should a drive fail.  Remote
being 10-20 miles away where someone would have to drive one over. 
RAID1 makes a lot more sense in that case, a second drive for each
branch location being a better deal than a spare PC.  Been my experience
the HDD is the most failure prone component and they have some user data
it isn't practical to keep backed up at the central site due to crappy
56Kbit connectivity.

> > 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 don't.  I'd prefer it passed control to a second copy of grub on hdX1
that would know what version is installed, but I can't find any way to
get grub to live anywhere but the MBR if all of the partitions are raid
members.

ext3 has made power glitches a lot more survivable but I don't ever want
a machine to stay down if I can help it.  So I let hdX4 rebuild the
primary on demand.  In addition when a new version of my default
software load is available the machines automatically pick it up and
trigger a rebuild.  A few version might include a new kernel so the
recovery side has to be able to go look at the primary and create a grub
entry.  Basically I'm reinventing wheels that grubby and
install-new-kernel already solve in the typical case.

> 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 ?

Because if the primary is really horked it's grub might not work.  Think
power glich which screw up the primary, start a reload and BAM, the
lights go out a second time before /boot gets restored.  Also it
wouldn't solve everything because as a belt & suspenders guy I also
built in the ability for the primary side to notice and automatically
apply new versions of the small system monitor partition.  Basically,
the problem is that with md you better have one and only one OS with the
loader in the MBR or you lose.

> I also tend to think a simpler solution (even if raid booting on
> partitions were available) would be to pxeboot your recovery image.

Wouldn't work out very well at the end of a 56/64Kbit leased circuit
where there are exactly two PCs, a staff workstation and a public access
one.  I know Linux security is pretty good but you won't catch ME
netbooting a machine that processes confidential info from a public PC. 
:)

I am already pondering it for use here at the main branch though.
 
> > 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".

Probably because anyone who tries it gives up because it is darned nigh
impossible.  I know I had to be pretty darned determined to make it as
far as I have.

-- 
John M.      http://www.beau.org/~jmorris     This post is 100% M$Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r





More information about the fedora-test-list mailing list