On Fri, 2008-08-29 at 13:58 -0400, Mark Belanger wrote:

Given that I have a machine with possibly multiple disks, each of which is bootable(has an MBR)....

Is there a command that will query the BIOS and tell me which disk is the default boot disk. BTW - this is x86.

The goal is to remotely reboot the workstation into the desired disk(which contain different centos versions).

The closest I can come without googling is a cat of /proc/cmdline. It gives *limited* information, but maybe it's enough for your needs? It only shows the root device and parameters passed to the kernel.

I suspect you could pass some invalid parameter to the kernel and it's only bad effect would be griping in the dmesg and message log files. If so, that parameter might appear in the .proc/cmdline file. This could tell you which disk booted?

I'm not familiar with any utility to do what you asked about. However, if you have no particular affinity for grub, LILO does provide an "on next boot" temporary facility. Risk: some consider rewriting the MBR dangerous. I *think* that's what LILO does, but not sure. It could just place some information in the unused sectors of the boot blocks area (I'd have to study up).

Of course, each disk that might be selected as the default boot for the next session would have to have LILO boot loaders in order to be disk and OS independent.

If you want to stick to grub, I'm pretty sure that it would have to be on each disk also.

Now having said that, once initial boot stages are done, the only difference (among Linux processes, that is) would be the contents of the initrd, which device partition(s) are mounted (root and non-root) and the kernel configurations - which kernel gets loaded and from where. Non-Linux OSs are handled via "chain" loaders.

In both LILO and Grub I think all this can pre-configured. In that fashion you can determine what runs regardless of which disk is the boot device. But you must know in advance what your options are for all this to work, of course.

With grub configs required in each possible boot partition, keeping the configs in synchronization might be a pain. OTOH, a different grub.conf for each bootable partition might solve your problem?

Ditto for the LILO stuff, sort of. If the LILO configuration file can be accessed at all (can mount and support the FS containing the configuration file), the lilo update process can place the needed boot blocks on any disk it can access (doesn't need the target mounted).

LILO has the slight edge because of the temporary "on next boot" option.

For grub, you can modify the "default" entry in the menu.lst (grub.conf) but, again, this would only affect the current boot partition's copy - you'd need to manually do them all.

Having said all that, why do you want to do it that way? It's much better (and easier for you to accomplish your stated goal) by setting up a single (and a backup, *maybe* - there's a couple more tricks needed for that if using LVM) boot partition that loads and handles the differences you need to support. Make your boot partition(s) larger, if needed, to support multiple versions of kernels, initrd, config.* and system maps. The using the "default" command of grub you can point to a boot configuration that will load different kernels, pass different initrds, mount different roots and even load different OSs (see the "chain" descriptions in "info grub").

If you prefer the LILO solution (if booting a new untested kernel, it's more preferable), again configure a "universal" configuration file to do the same sorts of things.

If you have an interest in the LILO solution, I wrote a hint some years back (not maintained since and may need intelligent application of current information to work) when I was doing (B)LFS. I don't know if it's still available as I think they switched to grub at some point and I don't think it has a maintainer. It allowed boot of any OS from any HD and included some supporting shells to make maintenance a little easier from the single copy of the configuration directory.

I could do some digging if you seriously want to pursue that. But I make no promises that I'll be able to find it. And I stopped doing LFS when I saw serious divergence in my philosophy and LFS's methodology about how you support users.

tia,

-Mark

HTH