This is something I've been looking to be able to do for years. I want a machine to be able to boot first into OS number 1 (always Linux), and then have that machine (after a time delay or some confirmation to proceed) boot into OS number 2 which will then be the one to keep running. OS number 2 may or may not be Linux.

Every time there is a hard reset, OS number 1 must always be the system that boots up. So changing the active OS in the bootloader is NOT a valid option, since if OS number 2 doesn't come up for some reason, a reset still needs to go back to OS number 1.

Basically, the boot loader always needs to boot to OS number 1. And OS number 2 would be selected by a volatile (gets reset by a hard reset) means, or be done directly by OS number 1 bypassing the bootloader.

I've dabbled with using kexec. Even (a new instance of) Linux has issues getting started via kexec due to the hardware state not having been reset by the BIOS. Something like Windows as the 2nd OS is likely to be a disaster via kexec.

I've wondered if a bootloader change could detect the right circumstances to choose OS number 1 vs. OS number 2. That would be if OS number 1 has indicated that OS number 2 should be used AND a hard reset has NOT taken place. If a hard reset has taken place, the bootloader must boot up OS number 1.

Using a virtual machine to run OS number 2 is not an option.

Yes, in theory, OS number 2 could still take over by changing to bootloader to always boot OS number 2. I'm assuming OS number 2 will be naive and not do that.

I think my best hope for this is the bootloader. But alternate boot flags are not sufficient for this.

If you had some small OS boot up first then test for what is what then decide what to reboot to using maybe grub by some auto edit.

The nearest thing I've been able to find which might provide the features you require comes from Technologic Systems. They claim that their bootloader can be used to boot into another OS from a running Linux system.

Finding their documentation took a couple of minutes. If I understand it correctly, it may be as easy as including a script in /etc/rc.d which has a timer in the code, then execute the reboot.

It was a brief read through, so don't hold me to it. Take a look; it may be what you need.

Hypothetically, Linux can be that small OS ... full kernel, maybe ... but a small user space. But that doesn't matter too much since disk space is cheap.

But this needs some difficult steps, like how to get the secondary OS running cleanly. Unless we can make the appropriate run through of reset logic in the BIOS and successfully get control back from that, I don't think kexec will be a practical tool except with Linux as the secondary OS (and I've run into some issues even with that).

So I think it needs to literally be a reboot by BIOS. That almost certainly means it goes to the bootloader. Now the bootloader will need logic to decide if the primary OS or the secondary OS should be booted. If it can be sure this was a soft reboot, then go to the secondary OS. If in doubt, always go to the primary OS.

We can always change what OS is referenced in the bootloader config. But doing that for the primary OS will break the certainty of getting back to the primary OS on hardware reset or power cycle. Only the secondary OS should be changed by this scheme.

I'm not concerned with hardened security preventing changes to which OS is primary. Instead, it just can't be part of the scheme. The scheme design must always leave unchanged what system will be booted as the primary whenever a hard reset happens. So it seems to all come down to whether there is a way for the bootloader to detect if it is booting from an OS triggered reboot (soft), or any other reboot (hard).

The link goes to a long list of documents, none titled in relation to booting. Any idea which document?

It would have been ideal if the BIOS call that an OS uses to reboot allowed an argument to specify a temporary alternate device to boot from, such as 0x81 instead of 0x80, or an argument to be passed to the bootloader (a number that is always 0x00 for hard boot, and whatever is passed for soft boot where 0x00 emulates a hard boot). Unfortunately, I've never heard of such a thing.

Passing an argument by anything written in permanent storage (e.g. hard drive) is not workable, since that needs to be ignore if there is a hard reboot.

I don't know of any plausible way to implement this where Window$ is OS #2. I don't think it's possible.

Just do not name your OS#1 anything containing the letters G R U and B in that order.
An operating system that can load another operating system in that manner and order WITHOUT virtualization is a "boot loader". IF you want a new and more powerful one, you may have to write it yourself.

What exactly is it that you seek to achieve with this? Your description is pretty good, but I fear I am missing the point. I do not see what this would do for you that might be desirable.

I agree, unless you have some desperately needed Linux only tasks to perform, why have to reboot ?
all I can suggest is a script that edits grub and issues a shutdown -r , though how OS2 edits grub I'll leave up to you.

Assume I have remote access to a means to cycle the power. And OS 1 may be booting from a read-only device like CD/DVD or SDHC with the media in the safe position.

One of the things I want to be able to do in system 1 is to restore system 2 back to a preserved state, so that it does not retain (certain) changes across a reboot.

Another thing I want to do is be able to remotely intervene via ssh to OS 1 where OS 2 doesn't have suitable configuration to do so (e.g. OS 1 waits a few minutes to let me in before it starts OS 2 which has no means to let me in).

I would not expect OS 2 to edit GRUB. I won't necessarily even use GRUB. And maybe OS 1 boots up from read only media.

It appears you want all of the advantages of a virtual machine, but you have dismissed that option. Unless you can completely specify your requirements then I'm not interested in playing whack-a-mole trying to guess your next restriction.
However, one approach might involve a powered external drive that's higher in the boot order. If you could remotely switch the power on and off, you would alter the boot selection that way.

I agree with the above. You might check into the ILO features of some good HP systems, but without virtualization there is no current way to do what you want.

Personally, I would do it WITH virtualization. It could be pretty elegant.
If you want to avoid that, then you will need to build your own solution.

If you do, I will be interested in what it looks like when compelted. A hardware and OS agnostic ILO might be rather sweet.

If the bios has a flag to denote soft or hard reset, it would in theory be possible to modify u-boot, or grub, to check for that and modify which os to load.

Looking at:

http://www.ouah.org/Bios_Information_Leakage.txt

It seems as though it may be possible to check for soft/hard reset, either offset 0x0F (one byte, with a bit acting as a flag) or 0x72 (two bytes, denoting soft reset flag)

I would guess that the actual areas may change with board or versions of bios, guess it depends on how standardised it all is.

I would say the best bet would be u-boot due to the way it stores default boot options, you'd just need to perform a switch test. However my knowledge of C and u-boot is quite limited as I was trying to resolve a problem with a beagleboard which the people on the mailing list helped me resolve.

Or Syslinux which I'm already more familiar with (and use for dynamically building bootable USB memory sticks).


Looking at the values at 0X0F that might be a number that progresses during the BIOS initialization steps. And there's no further info for what is at 0x72.

And this is in CMOS memory. I'm not sure if that's good or bad. If there is an area of memory that WILL be erased by the hard reset or power cycle, but has lingering data from an OS doing a soft reset, that might be sufficient info.

That's a likely issue.

If while in real mode in the bootloader I could look at memory to see what might have been running previously, if a hard reset would erase it (power cycle should eventually do so), that might do it.

I'm already set on modifying Syslinux due to more familiarity with it. I have deep knowledge of C, some of x86 assembler, and have tweaked bootloaders on a few architectures, before. It's this PC BIOS that is most confusing, in significant part because of so many varieties. Then there's the looming UEFI, which might solve it, or completely block a solution.

For those wanting to know what I'm doing, it really is trying to solve a general problem that has been the showstopper for many past ideas. In some cases the first OS will actually install the second OS on the fly each time, possibly by fetching the disk image from the network or other media. And I do want the boot process to look like a normal boot and normal hardware for OSes link Windows that get finicky about being on other than the first disk or in a VM. The 2nd OS might be doing VMs.

The point is, more than one past idea hit this roadblock. That's why I've classified the issue over the past many years as a "Holy Grail". If solved, it opens a number of possibilities. It needs a general re-usable solution.