On Thu, 2006-09-14 at 05:48 -0700, TimJowers@xxxxxxxxx wrote:
> Maybe someone can clear up the grub conf for me. Has anyone gotten this to
> work: two IDE/ATA drivers. Slave is a spare duplicate of the master. Goal is to
> be able to boot to Spare at any time and run it instead. What step am I
> missing?
Sweat, hard work, in-depth reading and testing? I had this implemented
95% (was adding routines to automatically skip compression of
ISOs, .gz, ...) when the MOBO did a "belly up" on me. The stuff is
laying around on different disks in different machines ATM.
When I get it reconstructed and finalized, I'll be glad to share with
the list. For now, here's what I remember (I'm not looking at code, so
you'll need to consider my memory was the second thing to go as I got
older).
Here is a synopsis of my recollections.
- Can't have two volume groups named the same. This has implications.
- Set up fstab to mount /dev/root instead of VolGroup00/... or -L ...
- Initrd has two "ignorelockingfailure" directives in the init script.
Adjust one to include the new volgroup(s) you may define.
- For carrying to new systems and installing (if not the boot disk?),
use "export" and "import" commands. Life will be easier.
- If you must carry data from a crashed system to an active one (you
were not able to "export") you may need to do some "renames" and
such on the receiving system. Can't have duplicate names (maj/minor
node carried on pv?) in a system.
- VG and LV names can be whatever you want. They don't have to be Vol*.
This can make it easier to setup fall-back positions. My 2nd HD has
VolGroupAA, ...AB, etc. LV names can be lvol0, lvol1, UsersHome or
whatever.
- The physical volume relates to a major/minor node number on the
originating system. Apparently (not confirmed) the pv metadata has
some record or relationship of this (so that the same vg/lv normally
gets the same node. Conflicts are possible as HDs are moved into
other systems, hence the need for "export" and "import" in normal
conditions.
- Using snapshot volumes, you can safely and effectively backup
live data. "Nice" can control the impact on any active users ATM.
- I did a "grub-install" on both disks and also set the grub config
file on each disk to allow access and "rooting" on both hd0 and hd1.
- If backup is current, this even allows for successful boot and
operations even when HD has not failed, but file system corruption
has made "production" version unusable. Just use the edit ability in
the grub boot menu to respecify the root or go to run level {1,2,3}
to adjust an fstab if the spoiled FS is, e.g. /home and then telinit
to run level X.
- I could test basic operations by changing boot sequence in BIOS. I do
not know if this holds when a HD fails (haven't tested to see if BIOS
still reassigns 0x81->0x80, 0x82->0x81, ... as it used to. This would
affect what you put in grub's conf file.). IIRC, it *seems* that
reassignment does *not* happen when the boot sequence is changed, but
it used to occur, using LILO. Haven't investigated fully.
> <snip>
HTH
--
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
