How to boot directly into Windows from kexec+Grub4DOS
#1
Posted 25 February 2009 - 07:23 AM
Suppose Windows is installed in the first partition of the first disk (hd0,0), how can I boot into it directly using kexec in Linux?
I did this:
# kexec -l grub.exe --command-line "root(hd0,0); chainloader (hd0,0)+1; boot"
# kexec -e
This takes me to the Grub4DOS menu. So, kexec is working, but apparently the command line arguments I'm passing to grub.exe are not doing the job right. What am I doing wrong here? Please help!
I see examples in the Grub4DOS manual that explain how to use an image file, but I just want to boot off the hard disk where Windows XP is installed.
TIA.
#2
Posted 25 February 2009 - 07:42 AM
# kexec -l grub.exe --command-line "root(hd0,0); chainloader (hd0,0)+1; boot"
# kexec -e
try this
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,0)+1;rootnoverify (hd0);boot" kexec -e
#3
Posted 25 February 2009 - 08:43 AM
Its working now. Can you please tell me the reason why "rootnoverify" is used here instead of "root". And I always thought root/rootnoverify needed to come before other commands like kernel/initrd/chainloader. Why doesn't the order matter here.
Thanks again!
#4
Posted 25 February 2009 - 09:33 AM
Hi,
Its working now. Can you please tell me the reason why "rootnoverify" is used here instead of "root". And I always thought root/rootnoverify needed to come before other commands like kernel/initrd/chainloader. Why doesn't the order matter here.
Thanks again!
rootnoverify (hd0) here only changes the root-drive number to hex 80, which is the first BIOS harddrive number. The subsequent boot command will assign the root-drive number to the DL register, and pass control to the boot sector.
Note that Microsoft's boot sector alway uses hard coded hex 80 as boot drive number, so the rootnoverify (hd0) can be omitted.
And the ending boot command here can also be omitted. So you can write it as follows:
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,0)+1" kexec -e
Since you have used the (hd0,0) prefix to "+1" in the chainloader command, you does not have to use an additional root (hd0,0) command before the chainloader command.
#5
Posted 25 February 2009 - 10:26 AM
Can you please tell me the reason why "rootnoverify" is used here instead of "root". And I always thought root/rootnoverify needed to come before other commands like kernel/initrd/chainloader. Why doesn't the order matter here.
To clear this aspect, there is no need to put a root or rootnoverify BEFORE the chainloader command, as long as you use "absolute" paths/devices.
Think at the sequence of grub4dos commands as setting a number of variables.
An example:
title some image map (hd0,0)/images/an_image.ima (fd0) map --hook chainloader (fd0)/io.sys rootnoverify (fd0) boot
Please note that the final boot command is implied when the sequence is inside a .lst or "configfile" and needed explicitly in command line mode.
The above could be written in a pseudo batch language as:
SET Variable_fd0=(hd0,0)/images/an_image.ima SET Variable_to_be_chainloaded=(fd0)/io.sys SET Variable_ROOT=(fd0) CALL BOOT %Variable_fd0%%Variable_ROOT% %Variable_to_be_chainloaded%
It is irrelevant whether the "Variable_ROOT" is "set" before or after the "Variable_to_be_chainloaded", while it is VITAL that "Variable_fd0" is set before the other two as otherwise the latter may be invalid.
Now consider the same entry above rewritten:
title some image map (hd0,0)/images/an_image.ima (fd0) map --hook rootnoverify (fd0) chainloader /io.sys boot
Since chainloader uses a "relative" path, the rootnoverify MUST come before the chainloader.
Another example, this:
title (hd0,0) chainloader (hd0,0)+1 root (hd0,0) bootand this:
title (hd0,0) root (hd0,0) chainloader (hd0,0)+1 boot
Are exchangeable, but this needs this order:
title (hd0,0) root (hd0,0) chainloader +1 boot
When you use "dynamic" or "implied" paths/devices, the root must come before other commands.
A final example:
title (hd0,0) find --set-root /tag_file_on_hd_0_0.tag chainloader +1 boot
Hope the above clears the matter.
jaclaz
#6
Posted 25 February 2009 - 01:01 PM
Please tell me which grub4dos version and Linux/Distro you where using.Hi,
Its working now.
#7
Posted 26 February 2009 - 04:48 AM
Regards
#8
Posted 17 December 2019 - 03:33 AM
try this
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,0)+1;rootnoverify (hd0);boot" kexec -e
hi, thank you for your reply. I have tried like above. My windows 10 is on third partition, and I put menu.lst in /boot/grub ,
then I type following cmd:
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,2)+1;rootnoverify (hd0);boot"
kexec -e
And then into a interface:
"
Booting 'find /menu.lst, /boot/.grub/menu.lst, /grub/menu.lst'
GRUB4DOS 0.4.6a 2019-10-28, Mem: 625K/1023M/0M, End: 368792
[ Minimal BASH-like line editing is ...]
"
In this interface, I cannot type or do anything, like a system pause.
Could you help me to figure out what is the problem or how to use grub4dos+kexec boot win10 correctly?
Edited by daxx, 17 December 2019 - 03:41 AM.
#9
Posted 17 December 2019 - 07:11 AM
grub.exe thru kexec method is not working with the newish hardware. Search other related topic for details.
If you try it with a virtual machine, it may run smoothly. The virtual machine's virtual hardware is not "new" enough, and still work fine with grub.exe and kexec.
#10
Posted 17 December 2019 - 08:35 AM
then I type following cmd:
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,2)+1;rootnoverify (hd0);boot"
Wait a minute.
Did you literally typed what you posted?
That is the result of one of the n (stupid) board updates that made a mess of some posts enclosed in "CODE" or "CODEBOX" tags changing some non-alphanumeric character to their ascii codes.
Your command is:
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,2)+1; rootnoverify (hd0); boot"
Wonko
#11
Posted 17 December 2019 - 08:51 AM
Wait a minute.
Did you literally typed what you posted?
That is the result of one of the n (stupid) board updates that made a mess of some posts enclosed in "CODE" or "CODEBOX" tags changing some non-alphanumeric character to their ascii codes.
Your command is:
kexec -l grub.exe --command-line="--config-file=chainloader (hd0,2)+1; rootnoverify (hd0); boot"
Wonko
emm, I only change the "hd0,0" to "hd0,2", cause my windows 10 is on third partition( /dev/sda3 on ubuntu).
But, I tried your command ,there is a error:
" GRUB4DOS 0.4.6a 2019-10-28, root is (0x80,0)
Processing the preset-menu ...
Error: No such command: chainloader(hd0,2)+1
Error: No such command: rootnoverify(hd0)
GRUB4DOS 0.4.6a 2019-10-28, Mem: 625K/1023M/0M, End: 368505"
And also cannot type anything.
I have struggle this problem for many days, please guide me, thank you very much.
Edited by daxx, 17 December 2019 - 08:52 AM.
#12
Posted 17 December 2019 - 08:58 AM
But, as you can see now the command line is actually passed through:
"Processing the preset-menu ..."
About:
"Error: No such command: chainloader(hd0,2)+1"
"Error: No such command: rootnoverify(hd0)"
There is a space between the command(s) and the arguments:
kexec -l grub.exe --command-line="--config-file=chainloader[SPACE](hd0,2)+1; rootnoverify[SPACE](hd0); boot"
Wonko
#13
Posted 17 December 2019 - 09:29 AM
But, as you can see now the command line is actually passed through:
"Processing the preset-menu ..."
About:
"Error: No such command: chainloader(hd0,2)+1"
"Error: No such command: rootnoverify(hd0)"
There is a space between the command(s) and the arguments:
kexec -l grub.exe --command-line="--config-file=chainloader[SPACE](hd0,2)+1; rootnoverify[SPACE](hd0); boot"
Wonko
Thank you.
Yes, now there is no Error when "Processing the preset-menu...",
but stil cannot type anything, and no menu entry.
My menu.lst is as following:
title (hd0,2)
chainloader (hd0,2)+1
root (hd0,2)
And, for guarantee, I put menu.lst in /boot/efi 、/dev/sda3 and /boot/grub.
So, I am very confused. Is the menu.lst placed in the wrong position, or is there a problem with the content, or the operation in linux is incorrect?
Thanks again for your kind response and help.
#14
Posted 17 December 2019 - 10:17 AM
grub.exe thru kexec method is not working with the newish hardware. Search other related topic for details.
If you try it with a virtual machine, it may run smoothly. The virtual machine's virtual hardware is not "new" enough, and still work fine with grub.exe and kexec.
Emm, I thought it would be okay because I saw that the source code has been updated recently.
But I still cannot figure out why kexec is not working in newer hardware .
#15
Posted 17 December 2019 - 10:21 AM
Amd again the ( ) etc. are artefacts.
your menu.lst should be:
title (hd0,2)
chainloader (hd0,2)+1
root (hd0,2)
but if you call grub.exe passing it a "--command-line" like yours the menu.lst won't ever be loaded.
So you are having THREE separate issues:
1) you are using incorrect syntax (the ( ) etc. CANNOT be parsed by grub4dos, there is the need of space between command and parameters, etc.)
2) you are expecting that grub.exe will load a menu.lst BUT you pass to it a command line that DOES NOT load any menu.lst, but rather attempts to direct booting/chainloading a bootsector or PBR
3) as tinybit stated there are a lot of other issues, once the above issues are solved, to actually use kexec with grub4dos on modern hardware
#16
Posted 17 December 2019 - 01:58 PM
But I still cannot figure out why kexec is not working in newer hardware
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.
#17
Posted 18 December 2019 - 01:59 AM
Amd again the ( ) etc. are artefacts.
your menu.lst should be:
title (hd0,2)
chainloader (hd0,2)+1
root (hd0,2)
but if you call grub.exe passing it a "--command-line" like yours the menu.lst won't ever be loaded.
So you are having THREE separate issues:
1) you are using incorrect syntax (the ( ) etc. CANNOT be parsed by grub4dos, there is the need of space between command and parameters, etc.)
2) you are expecting that grub.exe will load a menu.lst BUT you pass to it a command line that DOES NOT load any menu.lst, but rather attempts to direct booting/chainloading a bootsector or PBR
3) as tinybit stated there are a lot of other issues, once the above issues are solved, to actually use kexec with grub4dos on modern hardware
The first two can be (#1 has already been and #2 should have been now) solved, the last one #3 depends most probably on your hardware and at the moment there is no solution
Wonke
Emm, .
Thank your for your explanation。
As your advise, I tried two path to boot a windows10:
1)boot menu.lst : menu.lst as you advised, plus "kexec -l grub.exe kexec -e" -->not work;
2)booting/chainloading a bootsector or PBR directly: without menu.lst, only has the cmd :kexec -l grub.exe --command-line="--config-file=chainloader[SPACE](hd0,2)+1; rootnoverify[SPACE](hd0); boot" , kexec -e -->not work;
Whatever, thank you for your detailed analysis, at least I know this way is not impossible.
Is there another way to boot windows directly from linux?
#18
Posted 18 December 2019 - 02:08 AM
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.
Thank you for your explaination.
So, when the kexec+grub4dos working, it's not change from Pmode to real-mode?
As you said, before we can call BIOS INT in pmode, now we cannot do it . So, why not just load grub.exe and change to rmode to run it?
#19
Posted 18 December 2019 - 10:12 AM
Thank you for your explaination.
So, when the kexec+grub4dos working, it's not change from Pmode to real-mode?
As you said, before we can call BIOS INT in pmode, now we cannot do it . So, why not just load grub.exe and change to rmode to run it?
No.
grub4dos needs a realmode environment, not a pmode one.
The problem is: the realmode BIOS is not working after the Linux pmode AHCI driver gains control. Yes, we can easily switch the CPU from pmode to realmode, but the AHCI hardware will refuse to work in this situation, and it is by design - the newer AHCI specification prohibits the BIOS to work.
#20
Posted 19 December 2019 - 08:52 AM
No.
grub4dos needs a realmode environment, not a pmode one.
The problem is: the realmode BIOS is not working after the Linux pmode AHCI driver gains control. Yes, we can easily switch the CPU from pmode to realmode, but the AHCI hardware will refuse to work in this situation, and it is by design - the newer AHCI specification prohibits the BIOS to work.
Hi, I has viewed the source code.
G4D has the ability to run BIOS INT funcs, and the interface has many print message, that print func has called some BIOS INT func.
So, I am not sure why some BIOS INT func can be run, and other cannot.
Thanks.
#21
Posted 19 December 2019 - 03:26 PM
@daxx
看到你来自 China。我假定你懂中文。如果你懂中文,请在无忧启动论坛 grub4dos 讨论区提问。我看到后,会尽量给你一个详尽的答复。我的英语很差,我不能用我并不熟练的英语来频繁答复复杂的技术问题。(以下是基于百度翻译的译文)
See you come from China. I assume you know Chinese. If you know Chinese, please ask questions in the forum bbs.wuyou.net. When I see it, I will try to give you a detailed answer. My English is very poor. I can't use my unskilled English to answer complicated technical questions frequently.
#22
Posted 20 December 2019 - 02:48 AM
@daxx
看到你来自 China。我假定你懂中文。如果你懂中文,请在无忧启动论坛 grub4dos 讨论区提问。我看到后,会尽量给你一个详尽的答复。我的英语很差,我不能用我并不熟练的英语来频繁答复复杂的技术问题。(以下是基于百度翻译的译文)
See you come from China. I assume you know Chinese. If you know Chinese, please ask questions in the forum bbs.wuyou.net. When I see it, I will try to give you a detailed answer. My English is very poor. I can't use my unskilled English to answer complicated technical questions frequently.
好的好的
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users