bassense.blogg.se - Grub4dos boot into windoes

#Grub4dos boot into windoes driver
#Grub4dos boot into windoes code
#Grub4dos boot into windoes windows

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

#Grub4dos boot into windoes driver

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.

#Grub4dos boot into windoes windows

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

This seems to be the project mentioned in the article that was making it work. I found these slides as well as this github repo. Most of the work in this direction seems to be associated with the LinuxBoot project. Kexec'ing Windows doesn't seem to be a one-liner, but it has been done before. If you want to use gru4dos, you should only need to tweak the cmdline to fit your needs. Unconfigured, it falls back to the grub shell after some time. However, I managed to load grub4dos by downloading 0.4.4 from sourceforge and then running: kexec -l grub.exe It wasn't an option for me as it's legacy software. Grub.exe: Linux kernel x86 boot executable bzImage, version \353kHdrS\003\002, RO-rootFS, Normal VGA Lzma_decompress_file: read on /usr/lib/grub/i386-pc/lnxboot.img of 65536 bytes failedĪ quick look at Grub4Dos: # file grub.exe There also seems to be an issue occuring while loading (first few lines of debug output): Try gzip decompression. 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

You can then load grub2.bin from syslinux/isolinux/pxelinux/lilo orĪny other boot loader that supports linux kernel. It seems to be intended to be loaded as a kernel: Lnxboot.img would be a Linux kernel x86 boot executeable bzImage. Hint found on Arch Wiki and an old thread on the grub devel mailing list.

lnxboot.img as kernel and core.img as initrd.

piecing lnxboot.img and core.img together.

I'm not sure what format GRUB is using - a simple file command only produces this: /boot/grub2/i386-pc/core.img: dataĬurrently there seem to be these possibilities: 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. The error mentioned is still reproducible: kexec -l /boot/grub2/i386-pc/core.imgĪccording to kexec -help, the following types are supported at the moment: elf-x86_64 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. It seems to be possible to kexec Windows, but it seems to be experimental at best (and not well tested).