Create an independent Alternate Boot Environment

[Alzhy]

Anyone has steps on how to create an independently bootable alternate boot environment?

My servers currently have /dev/sda as Primary boot - LVM carved (sda1 as /boot and sda2 as PV for vg00).

Those also have a currently unused /dev/sdb which is the same kind of internal raided disk.

I want to use it as an alternate boot environment, selectable in BIOS as a boot device and be able to boot it WITHOUT having to disable sda - the first disk. The idea is it will be our rapid OS fall back environment in case of bad patching or someone introducing something on the primary. Regularly or before major patching, we will copy the OS to this aternate boot environment via cpio or tar.

Here's how I plan to do it:

- partition sdb exactly as sda, sdb1 and sdb2
- create PV out of sdb2, create LVM VG "vgbak"
- copy /boot and LVM vg00 filesystems to sdb
- update fstab on the vgbak environment
- edit /boot partition and grub config on sdb

What I am unsure at this time is the last step. How do I make the disk "bootable" and grub changes. Do I also need to make initrd changes?

TIA.


Alzhy.

[Michal Kapalka (mikap)]

hi,

check your raid controller it they support :

"Offline Mirror splitting and recombining"

so probably you could boot the system before patching and split the mirror, try to patch and if it's not working you could merge the raid form the splited unchanged disk's.

its only an idea, i never tried it before
mikap

[Alzhy]

Mike.. no it can't.

I think however I am on the right track of perusing that other logical volume out of my server's internal RAID sets.

I am not just sure how to truly make the other disk bootable and independent of the other disk WITHOUT disabling, removing that disk.

[Ralph Grothe]

Hi Alzhy,

can't you let grub install itself on sdb like so?

grub> device (hd0) /dev/sdb
device (hd0) /dev/sdb
grub> root (hd0,0)
root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... no
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.

[Matti_Kurkela]

Ralph's idea looks essentially correct to me.

His strategy apparently uses the GRUB shell from within the currently-running Linux installation (the "grub" command), although his copy/paste might have missed the first line that would have made it obvious.

The requirement to make initrd changes will depend on which Linux distribution you've chosen: if the initrd generator of your distribution of choice embeds things like the name of the root VG to the boot scripts inside the initrd, you will have to make some modifications. If the initrd is designed to obey what's specified in the kernel command line, initrd modification is not required.

A bit of background:
The trick is, you must be able to anticipate how the BIOS will see your disk configuration once the primary boot disk has been removed.

For a long time, there was no standard that would have allowed BIOS to report its boot-time view of the disks to a 32-bit OS. Currently such a standard exists, but its adoption is less than complete. Therefore, tools like the GRUB shell and the grub-install command may have to use various heuristics (= educated guessing) to know which disk identifiers to use for each disk device.

BIOS uses hard disk numbers, like 0x80 and 0x81; if the BIOS allows the selection of the boot disk, it usually works by re-mapping the disk numbers, so that the first hard disk, 0x80, will always be the one chosen for booting.

(If your normal boot disk is /dev/sda and you remove it, then at next boot, what was originally /dev/sdb will become disk 0x80... and once Linux boots up, it may end up called /dev/sda because the original /dev/sda is nowhere to be seen. However, LVM is not confused by this: instead of device names, it uses PV UUIDs to identify the disks.)

GRUB depends on BIOS to do its work, so GRUB's disk identifiers are directly mapped to the BIOS disk numbers: (hd0) is 0x80, (hd1) is 0x81, etc.

Ralph's "device (hd0) /dev/sdb" command in the GRUB shell is the key: it allows you to tell GRUB: "I know disk /dev/sdb will be (hd0) = BIOS disk 0x80 when you've actually trying to boot using this configuration." It overrides the auto-detection/guessing that the grub-shell normally has to do. The results of the auto-detection would match the current state of the system, not the *future* state you're anticipating.

MK

[Steven E. Protter]

Shalom,

I once whacked a server and had to do this in order to recover the system.

In my case I used an empty partition on the boot disk, but the principle is the same.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1400136

grub is the way to go, based on my experience.

SEP

[Alzhy]

Migz,

In this scenario the primary disk is not going to be whacked, unplugged, etc. I simply want 2 independently bootable boot environments. Since my boot env is LVM'd - the idea is to be able to tell initrd and grub what boot env to use. But I see now where I have been lacking and will soon try again. I will keep everyone updated.

But essentially what I like will have will be:

sda - Default BIOS Primary
/dev/sda1 --- /boot [label boot1]
/dev/sda2 --- PV for LVM vg00 (/, /tmp, /var. /opt)

sdb - 2nd Drive, Selectable at Boot/BIOS
/dev/sdb1 - /boot [label boot2]
/dev/sdb2 - PV for LVM vgbak (/, /tmp, /var. /opt)

Primarily, the altrnate boot environment shall be used as quick fall back in case of
bad patch, updates gone wild, etc. The idea is before any serios OS work is done, vg00 filesystems and /boot regularly keeps copied to vgbak. Rotuines to fix initrd and fstab will also be part of the regualr copies (which could be done via tar or rsynch or cpio).

Anyways -- I'll let you know how it goes. Finally getting our sandbox.

[Alzhy]

Breakthrough!

It works:

So I did the above.

mounted /dev/vgbak/root to /a
mounted /dev/sdb1 to /a/boot
edited /a/etc/fstab - to reflect LVM and boot
edited /a/boot/grub/device.map (hd0 -> /dev/sdb)
edited /a/boot/grub/grub.conf (to indicate vgbak as root)

Then - I recall the other thread I have where someone mentioned to fix my initrd image -- which I did by editing the contents to refelct LVM vg changes.


And Whoa! It works!

So I now have an indepently bootable alternate boot environment that can be updated via simple dump/restore or rsync or tar, etc. everytime serious OS work is done -- so we have a fall back environment.

Koolio Indeed.