[CentOS] detecting boot order

[William L. Maltby]

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