[kexec] It's Alive

[Miller, Shao]

Good day to all,

I'm carbon-copying Gert Hulselmans (booting guru) and Michael Brown of
iPXE _just_in_case_ they're interested.

I had the opportunity to compile this Windows kexec from an Ubuntu with
MinGW32.  In order to do so, I had to add KfRaiseIrql to MinGW's
libhal.a.  I had found a HAL.DEF from an e-mail by Danny Smith in the
thread "Re: [Mingw-users] _imp functions not found when linking" on Jun
22nd, 2008.

I changed the commented line:

  ;KfRaiseIrql

to:

  @KfRaiseIrql at 4

and ran:

  i586-mingw32msvc-dlltool --kill-at --output-lib libhal.a --def hal.def

and then overwrote /usr/i586-mingw32msvc/lib/libhal.a.

I have posted to the MinGW mailing-list to ask about the "proper"
generation of a HAL.DEF and will find out what they have to say about
that.

So I experimented with the built KEXEC.SYS with:

- memdisk and a DOS floppy initrd
- GRUB4DOS' GRUB.EXE (which is also Linux x86 kernel format)
- ipxe.lkrn (iPXE)

The MEMDISK test appeared to run; I saw all output right up until it
actually booted the DOS floppy.  My suspicion is that it hung right when
DOS would check the keyboard to see if the user hit F8 (or some other
DOS startup function key).

The GRUB4DOS test worked nicely.  GRUB4DOS used INT 0x13 to load a
config-file from the HDD and it chained the HDD's NTLDR.  NTLDR froze
just as soon as it was giving a BOOT.INI count-down timeout.  My
suspicion is that it hung because at that point it checks the keyboard
to see if a user makes any BOOT.INI choices.  Once I removed "choice"
from the BOOT.INI and tested again, Windows re-loaded from the HDD and
fully booted!  Congratulations, John!  Excellent!

The iPXE test failed without any output.  D'oh.  Well I can try a bit
more to see where it failed.

It might be the case that the MEMDISK test would work if checking the
keyboard can be avoided, so I've more tests in mind. :)

One possible use case that I have right now is 5,000 computers which
have an HDD image applied with a product called Faronics' Deep Freeze.
It is a disk filter driver (among other things) which discards writes to
the HDD, except for writes to virtual drives which it provides by
mapping to files which it controls or except for a list of partitions
and disks which are in its configuration's exceptions.

We thus cannot reasonably apply updates to these computers, since files
saved to the OS filesystem are lost at each boot.  HOWEVER, it is fairly
simple to disable Deep Freeze from a different booted OS...  Do you see
where I'm going with this? :)  kexec might allow us to boot some minimal
Windows, perhaps via MEMDISK, where SMSS.EXE has been replaced by a
"native-mode" alternative which will disable Deep Freeze on the local
HDD OR apply some changes to the local HDD, then simply reboot.

Ha!  I'll post again after more fun.

Thank you, John Stump!

- Shao Miller