Jump to content











Photo
- - - - -

How to boot directly into Windows from kexec+Grub4DOS


  • Please log in to reply
21 replies to this topic

#1 shuss

shuss
  • Members
  • 3 posts
  •  
    India

Posted 25 February 2009 - 07:23 AM

Hi,

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 tinybit

tinybit

    Gold Member

  • Developer
  • 1173 posts
  •  
    China

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 shuss

shuss
  • Members
  • 3 posts
  •  
    India

Posted 25 February 2009 - 08:43 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!

#4 tinybit

tinybit

    Gold Member

  • Developer
  • 1173 posts
  •  
    China

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 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

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)

boot
and 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. :cheers:

jaclaz

#6 mr_

mr_

    Frequent Member

  • Members
  • 355 posts
  •  
    Germany

Posted 25 February 2009 - 01:01 PM

Hi,

Its working now.

Please tell me which grub4dos version and Linux/Distro you where using.

#7 shuss

shuss
  • Members
  • 3 posts
  •  
    India

Posted 26 February 2009 - 04:48 AM

Grub4DOS 0.4.2 and ASTLinux.

Regards

#8 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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 tinybit

tinybit

    Gold Member

  • Developer
  • 1173 posts
  •  
    China

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 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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

 

Did you literally typed what you posted? :w00t:

 

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"

 

:duff:

Wonko



#11 daxx

daxx
  • Members
  • 8 posts
  •  
    China

Posted 17 December 2019 - 08:51 AM

Wait a minute. :dubbio:

 

Did you literally typed what you posted? :w00t:

 

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"

 

:duff:

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 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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"

 

:duff:

Wonko



#13 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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"

 

:duff:

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 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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 

 

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 :(

 

:duff:

Wonke



#16 tinybit

tinybit

    Gold Member

  • Developer
  • 1173 posts
  •  
    China

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 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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 :(

 

:duff:

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

Is there another way to boot windows directly from linux?



#18 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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

 

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 tinybit

tinybit

    Gold Member

  • Developer
  • 1173 posts
  •  
    China

Posted 18 December 2019 - 10:12 AM

Thank you for your explaination. :D

 

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 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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 tinybit

tinybit

    Gold Member

  • Developer
  • 1173 posts
  •  
    China

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 daxx

daxx
  • Members
  • 8 posts
  •  
    China

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.

 

好的好的
 






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users