It seems to be possible to kexec Windows, but it seems to be experimental at best (and not well tested).

GRUB

It's not possible to kexec the grub core.img by itself (as it doesn't seem to have a compatible binary format), also see this bug report on launchpad. The error mentioned is still reproducible:

kexec -l /boot/grub2/i386-pc/core.img 

According to kexec --help, the following types are supported at the moment:

elf-x86_64 multiboot-x86 multiboot2-x86 elf-x86 bzImage64 bzImage beoboot-x86 nbi-x86 

If you want to load a different loader, it would need to be in one of these formats or the compatibility would have to be added. I'm not sure what format GRUB is using - a simple file command only produces this:

/boot/grub2/i386-pc/core.img: data 

Creating a bootable GRUB Image

Currently there seem to be these possibilities:

• grub2-mkimage
• a part of core.img (kernel.img)
• piecing lnxboot.img and core.img together. See @Ardwena' answer.
• lnxboot.img as kernel and core.img as initrd. Hint found on Arch Wiki and an old thread on the grub devel mailing list.

lnxboot

lnxboot.img would be a Linux kernel x86 boot executeable bzImage. It seems to be intended to be loaded as a kernel:

You can then load grub2.bin from syslinux/isolinux/pxelinux/lilo or any other boot loader that supports linux kernel.

Kexec does load it, but crashes when executing:

kexec -l /usr/lib/grub/i386-pc/lnxboot.img --initrd=/boot/grub2/i386-pc/core.img --debug 

There also seems to be an issue occuring while loading (first few lines of debug output):

Try gzip decompression. Try LZMA decompression. lzma_decompress_file: read on /usr/lib/grub/i386-pc/lnxboot.img of 65536 bytes failed [...] 

Grub4Dos

A quick look at Grub4Dos:

# file grub.exe grub.exe: Linux kernel x86 boot executable bzImage, version \353kHdrS\003\002, RO-rootFS, Normal VGA 

This should mean that it is compatible. It wasn't an option for me as it's legacy software.

However, I managed to load grub4dos by downloading 0.4.4 from sourceforge and then running:

kexec -l grub.exe kexec -e 

Unconfigured, it falls back to the grub shell after some time. If you want to use gru4dos, you should only need to tweak the cmdline to fit your needs. This thread should still apply.

Windows

Kexec'ing Windows doesn't seem to be a one-liner, but it has been done before.

Most of the work in this direction seems to be associated with the LinuxBoot project. Github

I found these slides as well as this github repo. This seems to be the project mentioned in the article that was making it work.

It seems to be possible, but a lot of work (and no "production-ready" solution available - At least I haven't found it yet). Unfortunately there doesn't seem to be a lot of documentation for LinuxBoot, so you may have to ask the developers. There may already be a more straightforward way to do this.

The reason why kexec-ing into Windows is so difficult and complicated is because the internal design mechanism of kexec has an imperfection that, it assumes all OS boot loaders loads OS kernel image in a similar way, which is clearly not the case. For example, some OS kernel image must be loaded starting from some special memory address offset, some OS may require loading additional files (that containing driver info) alongside OS kernel image, etc. Since we have no control over how an operating system loads its kernel image, or will load its kernel image in a future release, the current way of kexec-ing into another OS/kernel is not going to work very well in the long run.

The more universal/compatible way (as I propose) of kexec-ing into another OS is to load the real-mode boot-sector boot code, quit the protected mode, and then jump directly into the real-mode boot code entry point. This is the most universal way because any operating system's real-mode boot-sector boot code can always be loaded starting at any memory address, that is how BIOS (different computer manufacturers make different BIOS) boots into an operating system (unless an OS does not want other BIOS to install or boot it, e.g., Apple, they can impose proprietary restrictions on how to load boot-sector boot codes). In this way, we can always boot into any operating system regardless of how its boot code loads its OS kernel image simply because we are running its own boot-sector boot code directly. Moreover, this mode does not introduce any slow-down because boot-sector boot code is small and thus fast to load, and the difference in loading a large kernel image file in real mode vs in protected mode is not very big.

However, to achieve this is very challenging because:

1. For all modern OS, once they enter protected mode from real mode, the real-mode memory is over-written by some descriptor tables or page tables entries. Thus, there is no backup. However, real mode boot codes use BIOS interrupts to access hardware IO, so without restoring the original real-mode memory map, they won't be able to load kernel image file from hard-disk. This problem is tricky but solvable. We can install some special Linux boot loader that takes a memory snapshot before entering protected mode and it only needs to be done once for all on one machine.

2. Not all processors well support going back to real mode from protected mode. Modern processors are designed for booting into an OS (entering protected mode from real mode), rather than un-booting out of an OS (returning to real mode from protected mode), for production cost and efficiency reasons. Thus, the behavior of returning to real mode from protected mode is not well tested and thus very much undefined. Since this behavior varies in each model, there is no control thus no guarantee of on which brand/models processors will it work correctly.

3. Only Intel X86 processors have real mode and protected mode (because it went through a very early stage legacy technology). Thus, the mechanism of rebooting from boot sector will be different for different processor architectures, not necessarily involving returning to real mode from protected mode, but may involve some other switches in processor operating states.

Nevertheless, it should work in principle if everything is correctly taken care of. In the future, Linux should have the capability of kexec-ing into any mounted boot-able partition (but not necessarily marked as boot-able because each hard-disk can only have one partition that is marked as boot-able, or BIOS will report an error and refuse to boot) from any hard-disk directly without a full hardware reboot which is much slower. This shed more light and hope to Linux ^_^

You need to have grub installed and the Linux system as the default boot.

On the linux system create a crontab entry like this:

@reboot /do/some/stuff 

Where /do/some/stuff is a script to perform whatever tasks you need to do. At the end of the script add the following:

#!/bin/bash # # Do something here sudo grub2-once "Windows" sudo reboot 

It should then reboot into windows provided the grub menu item for windows is "Windows".

At the next reboot it will go back into linux and do the same thing.

Not exactly what has been asked for, but starting a Windows-VM using Linux is a solution feasible, if you have got enough power on that machine.

I can recommend VirtualBox for this. There you can configure VMs to autostart during bootup, to.

By modifying the runlevel relationships you can time when to start that windows-VM. With shared folders you can even use a signalling mechanism between Linux and the Windows VM.

kexec might work if you combine these two grub images: lnxboot.img and core.img, like...

cat lnxboot.img core.img > your-kexec-able.img 

Worth trying that.

EDIT:

Now that I looked inside the images, lnxboot.image looks more like an "ELF" than lnxboot.img, so try that one too.

EDIT:

Aparently, the /boot/grub2/i386-pc/xxx.img images are not to the liking of kexec. Then why not try using grub-mkimage to genrate some different formats, and see what works? From the man page, -O, --format=FORMAT supports a whole bunch of other formats. Maybe try the x86_64-xen format.