This is the actual set of commands (I presume you are using them assembled in your preset_menu.lst) that you are using and that create the Error 25, right?
default 0
timeout 5
title Windows
rootnoverify (hd0,0)
chainloader /bootmgr
How (exactly) are you invoking the grub4dos via kexec?
Usually when using indirect loading one would use a config file instead of modifying the embedded menu.lst.
Yes, that is the set of commands I was using. I've been able to use root (hd0,0) as well as rootnoverify (hd0,0) - I just wanted to see whether it would fix my problem or not. Obviously, it did not lol.
A big problem that I ran into (and is a large reason as to why I chose to modify the embedded menu.lst) is that Grub4Dos would take far too long trying to find menu.lst.
Try using a pre-compiled version (latest) untouched.
In it, get to command line (press c if you enter into a menu.lst) and try issue the
geometry (hd0)
command.
I have a terrible problem that I think is unrelated (but may not be): after kexec-ing, my USBs stop being powered so I'm unable to use my keyboard to get to the command line.
I don't have this problem on VMs, but I also don't have my initial problem on VMs. :|
I will add the command to my menu.lst and see what happens, however.
Unless I am reading it wrongly, in the post on github, you have an initial:
root is (0x80,0)
It is possible (please read as probable) that the issue lies in the kexec chainloading or in the *whatever* your Linux kernel does before running kexec, and this could also be *something* that is only triggered on a specific motherboard/BIOS only (hence it works in the VM but doesn't on your real hardware, see:
http://reboot.pro/to...c-specifically/
Generally speaking (and not particularly useful to solve the actual problem, but JFYI) if you cannot
root (hd0,0)
and have to use instead
rootnoverify (hd0,0)
it is a sign that *something* is not right in what grub4dos "sees" about the disk(s).
The actual code that is run to kexec into grub4dos is from a Python init script:
subprocess.run(["/sbin/kexec", "-l", "/sbin/grub.exe"])
subprocess.run(["/sbin/kexec", "-e"])
Since grub4dos can be booted by GRUB2 "directly", you can try using kexec to run GRUB2 and see if it works, though I believe you need to make a "custom" compile of GRUB2 as ELF:
https://lists.gnu.or...4/msg00367.html
(very old note. I don't think that anyone was interested in the issue)
But can you get to GRUB2 from the grub4dos (loaded by kexec)?
At least from my own research, it seemed like the ability to kexec into Grub2 was... planned?
https://bugs.launchp...ls/ bug/1297316 But even with your link, it feels like kexec-ing to grub2 is a dead-end. :/
Found it (couldn't find it before) a thread where tinybit explains the probable reasons for this issue:
http://reboot.pro/to...-kexecgrub4dos/
Wonko
Ah, I see:
Kexec might work with newer hardware, but kexec + grub.exe cannot.
Why? because grub.exe requires a working real-mode BIOS environment. With newer hardware - Intel's AHCI - the BIOS is no longer functioning once the Linux protected-mode (AHCI) driver is installed (the driver is normally built-in to the kernel).
With old hardware, a protected-mode driver does not destroy the realmode environment, so after switching from protected-mode to real-mode, BIOS will continue to work fine.
That is why "kexec+grub.exe" works on virtual machines(qemu, etc.) but does not work on newish real machines.
Some part of the BIOS is functioning well, others not.
In your case, the video/display is OK. The keyboard input is not working, even the CTRL+ALT+DEL is not functioning.
The BIOS could simply hangup on a INT13 call. So even CTRL+ALT+DEL might not work. The intel AHCI specification prohibit the hardware to return to real-mode after pmode drivers gains control.
My keyboard not working is related, then. The thread just kind of trails off, so I'm really not sure if there even *is* an answer but: what should I do?
I am a little confused as to how the BIOS specification is IDE but AHCI still interferes with this? I must be misunderstanding something.
EDIT:
I have been booting USB sticks using grub4dos for many years, even before the SATA disk were developed, and exactly same USB stick is capable to boot and have full read/write access to HDDs on PCs using IDE or AHCI drivers, then the problem should not be on grub4dos, I'm agree with Wonko it seems more related to the way you call grub4dos
As I don't know how old are your PCs it is better to play the safe way, get an spare USB stick format it using RMPrepUSB (see attached picture No. 1), install grub4dos, boot from it, and just try to boot Win10 from it with following commands on your menu.lst (since you said the system is Bios booting not UEFI, remember grub4dos do not work on UEFI):
NOTE: It is better to have The Metro boot or GUI boot disabled, see attached picture No.2
Then if the PC boots fine (as it should be), you need to start checking for the issue on other part of your booting process.
alacran
I made a USB following these specifications and am able to boot into Windows just fine, so it must be something to do with my script/kexec.
Edited by DapperDeer, 18 June 2020 - 08:27 PM.