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