Jump to content











Photo
- - - - -

Grub4Dos via Kexec (PlopKexec, specifically)

grub4dos kexec keyboard hang ubuntu

  • Please log in to reply
22 replies to this topic

#1 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 06:37 PM

Hi,
I know this has been discussed here before, and I've read the relevant previous threads on this topic (http://reboot.pro/to...to-boot-win-xp/ and http://reboot.pro/to...execgrub4dos/), but as far as I can tell those users have solved their problems and the solutions don't appear to work for me unfortunately.
Here's what I'm trying to do and what currently is happening:
- I'm running PlopKexec (https://www.plop.at/en/plopkexec.html) based on kernel 3.18.2. With this I can successfully boot Ubuntu running on an add-in disk that can't be otherwise detected. Now, I'm also wanting to load my Windows installation on that disk via Grub4Dos. I've tried loading different versions of Grub4Dos with different results, but none work right.
In particular, all of the more recent versions hang at "Loading GRUB". The best result I've had so far is with Grub4Dos 0.4.1 (ancient!), which gets me a grub prompt. In the latter case, I then have the unresponsive keyboard problem which is not fixed with USB devices sadly.
A few other observations: I get the same behaviour if I attach this disk as the regular HDD and try using kexec from within Ububtu (12.10, hang with 4.1+ and unresponsive prompt with 4.1). If I try it from within Ubuntu 15.04, I get blank screens in all cases.
I'm aware that this has a relatively slim chance of working, but since the other users were able to solve their issues eventually I figure I'd give it a shot.
Questions I have are: What is the difference between 0.4.1 and the later versions that would make it not hang, and what is the difference between successfully loading Ubuntu via Kexec (no keyboard problems) and loading Grub4Dos (keyboard problems)?
Thanks,
 
Rafael
 


#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 June 2015 - 06:43 PM

From the link you gave:

PlopKexec is based on a Linux Kernel and can load only other Linux kernels!

Why MUST you run PlopKexec?

What device are you booting from (CD)?



#3 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 06:46 PM

Because as far as I can tell, it's the only way I have of accessing a disk that's connected via a USB3 mini PCIe card and a USB3-SATA adapter. kexec-loader didn't see the disk. Furthermore, I believe it should work because I get the exact same behaviour if I try to use kexec from within Linux with the HDD connected normally (as has been solved before) and PlopKexec. So my thought is if I can get it to work within Ubuntu that should transfer to Plopkexec. At least worth a shot, in my head.

 

R

 

Edit: It's a fairly convoluted chain of bootloaders. The main disk is a GPT Hackintosh that loads Chameleon initially, then Grub from which I get to Plopkexec and see my 2nd HDD, then Ubuntu on the 2nd HDD. THe 2nd HDD also has Windows on it, which I'd like to load via the last step.


Edited by flyingfishfinger, 11 June 2015 - 06:49 PM.


#4 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 June 2015 - 06:54 PM

AFAIK Plop contains only support for USB 2.0  and 1.1.



#5 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 06:59 PM

No, it boots Ubuntu fine from the 2nd HDD. From his site:

 

Compiled for i486, Linux Kernel 3.18.2, 45 MB RAM required.

USB support: USB 1.1, 2.0, 3.0
PC-Card (PCMCIA) and PCI Express is supported

 

That's not really the question though, since that already works. Question is how to get kexec (and derivatives) to load Grub4Dos...

Thanks,

 

R



#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 June 2015 - 07:09 PM

OK, but grub4dos uses the BIOS and if you are using an Add-in card, then the BIOS won't see the card or any devices attached to it (unless it contains an add-in BIOS ROM module or Kexec patches the BIOS).

 

So although you can boot to Ubuntu via Kexec, I don't think you can boot to the disk via grub4dos (even if you can boot to grub4dos).

 

For grub4dos, try 2015-06-05 0.4.6a version at http://grub4dos.chen...ries/downloads/



#7 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 07:27 PM

Ah, ok. That probably answers my question then, but I'll see if this Grub4Dos loads after I solve this error: "GRUB requires a working absolute objcopy; upgrade your binutils".

They're at the latest version already, is this a known problem?

 

R


Edited by flyingfishfinger, 11 June 2015 - 07:29 PM.


#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 June 2015 - 07:29 PM

Why not just download the precompiled version?

http://dl.grub4dos.c...a-2015-06-05.7z



#9 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 07:32 PM

Thanks. Sorry, I can't read much of that site in it's current language..

 

R

Update: No dice. I get a prompt (yay!), but no keyboard (even USB) :(


Edited by flyingfishfinger, 11 June 2015 - 07:46 PM.


#10 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 June 2015 - 08:10 PM

Update: No dice. I get a prompt (yay!), but no keyboard (even USB) :(

Well, if you get to the grub> prompt of grub4dos then (though it will be longer/more tricky) you can use a menu.lst (or maybe edit the embedded one inside the grub4dos).
Can you detail EXACTLY how you are loading grub4dos currently?
Try also an older (more stable branch) of grub4dos, the 0.4.5 one, this:
http://grub4dos.chen....5c-2015-05-18/
http://dl.grub4dos.c...c-2015-05-18.7z

:duff:
Wonko

#11 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 09:12 PM

 

 

Can you detail EXACTLY how you are loading grub4dos currently?

 

Certainly. As mentioned, I have 2 HDDs. The first, main HDD contains OS X, Win7 and Ubuntu on their respective partitions, and the whole first disk is booted via Chameleon. The 2nd HDD is attached via the expansion card (invisible to Chameleon) and contains (in this case) Ubuntu, Windows Vista, and OS X.

 

On my main HDD, I've added an entry to the Grub menu (loaded from Chameleon when I boot Ubuntu) that points to the PloPexec kernel, which resides at the root of the Ubuntu partition on the main drive. When I load that, it scans for all drives it can detect (which includes additional HW invisible to the previous bootloaders) which have a syslinux-like config file.

On the 2nd HDD, I have such a config file on its Ubuntu partition, so it is detected by PloPkexec. In this config file, I have two entries, one for Ubuntu on this same (2nd) HDD which points to the local kernel and initrd. This is how I load Ubuntu. The second entry points to grub.exe, which also resides at the root of the Ubuntu partition on the 2nd HDD. It is detected by PloPkexec and loaded, but either hangs on loading or drops to a prompt with no keyboard. 

I don't know how it sees the disk layout, so I'm not sure what HDD's I would put in a --config-file argument to it.

 

R



#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 June 2015 - 09:34 PM

Certainly. ....which have a syslinux-like config file.

Good :).

.... In this config file, I have two entries, one for Ubuntu on this same (2nd) HDD which points to the local kernel and initrd. This is how I load Ubuntu. The second entry points to grub.exe, which also resides at the root of the Ubuntu partition on the 2nd HDD. It is detected by PloPkexec and loaded, but either hangs on loading or drops to a prompt with no keyboard.

Fine. :fine:

I don't know how it sees the disk layout, so I'm not sure what HDD's I would put in a --config-file argument to it.

Well, you can try adding n entries to that "syslinux-like config file" each one pointing to a menu.lst on the root of corresponding partitions/volumes,  and try which one (if any) works and loads the menu.lst , or - as only hinted before - modify the "embedded menu.lst" in grub.exe.
 
Adding to it as "default" entry a root command should provide you with the info on where the root is established (hopefully) when it is booted.
If you open grub.exe in a hex editor and go to the end of it, you will find the embedded menu, which should be something like:
 

pxe detect
configfile
default 0
timeout 1

title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst
errorcheck off
configfile /boot/grub/menu.lst
configfile /grub/menu.lst
if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
if "%@root:~1,1%"=="f" && find --set-root --devices=f /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst
find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst
errorcheck on
commandline

title commandline
commandline

title reboot
reboot

title halt
halt

which can be edited/modified.
 
Disclaimer: this is done normally and works with grldr and while it should work for the files seen as DOS .exe as well :unsure:, when chainloaded this way grub.exe is actually a Linux Kernel (or however a ELF executable) so this may work or completely fail to work.
 
:duff:
Wonko

#13 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 11 June 2015 - 10:14 PM

I think I'm not using the --config-file parameter correctly. I put in a --config-file="root (hdx,y); configfile /menu_test.lst", which I assume would be loaded if found.

 

What I get instead when selecting ANY of the added choices:

 
"Grub4DOS 0.4.5c 2015-05-18, root is (0x80, 0)"

"Processing the preset-menu"

 

and hangs there. 

 

R



#14 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 June 2015 - 10:43 PM

Well, those may be two separated issues.

If you prefer the --config-file=<argument>
accepts two different kind of arguments:
type #1 is the (absolute :unsure:) path to a menu.lst FILE, examples:
--config-file=(hd0,0)/menu.lst
--config-file=(hd0,1)/menu1.lst
Type #2 is a sequence of commands separated by ; inside double quotes, examples:
--config-file="root (hd0,1);chainloader +1"

your:
--config-file="root (hdx,y); configfile /menu_test.lst"
is of type #2, and seemingly fine :) but in this case it is entirely possible that (for whatever reasons) the first command:
root (hdx,y)
*somehow* fails to execute correctly and the second one:
configfile /menu_test.lst
which is a "shorthand" for:
configfile ()/menu_test.lst
where () means <current root> is interpreted as (A suffusion of yellow)/menu_test.lst :w00t: and hangs the booting.

Or it is possible that the mere attempt of establishing root causes the hang.

It is also possible that the "standard" embedded menu is causing *something* that in combination with those --config-file parameters results in the hang.

I would rather try:
--config-file="root (hdx,y); root"
and
--config-file="root"
and
--config-file=(hdx,y)/menuy.lst
--config-file=(hdx,z)/menuz.lst
etc.

but really cannot say if that would change anything.

The whole issue is that normally you first try things (and solve problems) manually on command line and then insert them when successful in a menu.lst, but since you have not a working keyboard you are forced to test *randomly* (but not much) several different approaches.
I told you it would have been longer/tricky, didn't I?

The main difference (if I recall correctly) between the 0.4.5c and the 0.4.6 series should be the lack or presence of an "own" grub4dos USB stack which maybe interferes with your complex setup (hence the suggestion to try the 0.4.5c by me) or maybe is specifically needed in it (hence Steve6375's suggestion) and it is entirely possible that an earlier version (though not as ancient as the 0.4.1 you mentioned earlier, let's say the 0.4.4 2009-16-10) could succeed (because it has less features) while more modern verions have something interfering. :(

:duff:
Wonko

#15 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 June 2015 - 11:34 PM

Maybe you could just try the 'find' command, just to see what drives grub4dos can detect?

If the USB drive does not show in the list then there is no point in continuing...



#16 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 12 June 2015 - 12:31 AM

Good call. I put --config-file="find;pause 5" in the PloPkexec file, interesting result:

 

"Grub4DOS 0.4.5c 2015... root is (0x80,0)

Processing the preset-menu...

 (hd0,0)"

 

hang

 

That's odd though, since both HDD's have more than 1 partition.

Thoughts?

 

R



#17 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 12 June 2015 - 12:42 AM

I think I'm not using the --config-file parameter correctly. I put in a --config-file="root (hdx,y); configfile /menu_test.lst", which I assume would be loaded if found.

 

What I get instead when selecting ANY of the added choices:

 
"Grub4DOS 0.4.5c 2015-05-18, root is (0x80, 0)"

"Processing the preset-menu"

 

and hangs there. 

 

R

 

So it hangs at "the preset menu", meaning the preset menu caused the hangup.

 

Try to modify the preset menu, or just add/insert a line of "commandline" at the very beginning of the preset menu and try again, to gain a command line. Can you gain a command line and use your keyboard? If your USB keyboard not working, try using a PS/2 keyboard.



#18 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 12 June 2015 - 03:04 AM

Well, here's a curveball. This problem seems to have nothing to do with the hardware!

 

I put the 2nd HDD into another (identical laptop) as its main drive (meaning that doesn't have any of the expansion hardware at all) and ran PloPkexec off of a flash drive.

Exact same result! It hangs after listing (hd0,0)...

 

R



#19 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 12 June 2015 - 03:04 AM

Good call. I put --config-file="find;pause 5" in the PloPkexec file, interesting result:

 

"Grub4DOS 0.4.5c 2015... root is (0x80,0)

Processing the preset-menu...

 (hd0,0)"

 

hang

 

That's odd though, since both HDD's have more than 1 partition.

Thoughts?

 

R

 

Good report.

 

It hangs at trying to access disk sectors via BIOS. That is to say, the BIOS is not working at this moment.

 

Why was the BIOS not functioning normally?

 

It could be caused by two:

 

1.  The motherboard.

2.  The Linux kernel or Linux device drivers.

 

For those (so-called)"GOOD" motherboards, you can use any Linux kernel and any Linux drivers with any grub4dos versions, no problem will occur.

 

For a (so-called) "problematic" motherboard, you have to simplify your Linux kernel(mostly by deleting the PCI device module and PCI device drivers) in order to work fine with grub4dos(Note: Your KEXEC works under this Linux OS; If there were no Linux environment, you could not use your KEXEC at all). It is the Linux device module/driver which destroyed the real-mode BIOS environment on the (so-called) "problematic" machines (thus grub4dos will crash at some or all BIOS calls). If someone can fix the Linux device module and device driver and let them not destroy the realmode BIOS environment, there will be no problem any more.



#20 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 12 June 2015 - 03:15 AM

Another update:

If I run the same command (find) from WITHIN Ubuntu (using plain old kexec), still SAME RESULT (hd0,0) and hang.

Therefore it's not a problem with PloPkexec either, but with kexec or Grub4Dos!

 

R



#21 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 12 June 2015 - 05:46 AM

The problem should have nothing to do with kexec/grub4dos, but something with the kernel and/or motherboard.

Suppose no one would solve the kernel issue mentioned in my previous post, you might have to give up, I mean you could not use grub4dos with success for the problematic machines.

Note that Ubuntu is a Linux and it has its kernel. If you don't change the kernel and the machine, then nothing will change, I mean, the problem will still be there, and will never go away.

For the problematic machines, you have to build your own kernel for use with grub4dos. You should strip out all the PCI relevant drivers, or you may write your own PCI drivers and you should not touch / hurt BIOS environment. Otherwise, you simply cannot use grub4dos(for the problematic machines).

#22 flyingfishfinger

flyingfishfinger

    Newbie

  • Members
  • 11 posts
  •  
    United States

Posted 12 June 2015 - 06:03 AM

Yes, I meant kernel or Grub4Dos problem. The reason I say that is because different versions of Grub4Dos achieve different results (some get to a prompt, some don't).

 

I can successfully call Grub4Dos from regular GRUB and it works fine, the way I expect.

 

I will try different Linux distributions and see if I can make it work that way.

 

R



#23 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 12 June 2015 - 06:22 AM

flyingfishfinger, on 12 Jun 2015 - 2:03 PM, said:
Yes, I meant kernel or Grub4Dos problem. The reason I say that is because different versions of Grub4Dos achieve different results (some get to a prompt, some don't).

I can successfully call Grub4Dos from regular GRUB and it works fine, the way I expect.

I will try different Linux distributions and see if I can make it work that way.

R

There are no differences, I mean, you can ignore the differences. They both lost the BIOS environment and cannot operate/function normally under grub4dos.

Grub is not Linux, and grub might never destroy the BIOS environment, thus, grub can load grub4dos without any issue.

I suggest you build your own Linux kernel, stripping out almost all hardware drivers. Actually that is what I did several years ago for one machine of that time.

The distributed kernels generally enabled the bad PCI code and you seem to always fail on your problematic machine.


Well, not only Linux could destroy the BIOS environment, but could also DOS and Windows and any other OSes.

As is known to everyone, DOS destroyed the Interrupt-Vector-Table. So we have to try and restore the Vectors as many as possible before we transfer control to the grub4dos main function.

Windows also destroyed the BIOS environment, and we could hardly restore it. That is why we could not have a utility of "GRUB for Windows".

Similar situation for Linux. But Linux is open-source. So in principle, the problem could be solved someday by someone in future.


For instance, Linux could destroy some of the int15/E820 memory that is required for BIOS. By an (probably)undocumented specification, some reserved E820 memory blocks that have been in-use by BIOS can be destroyed and re-used by an OS. By re-using such a memory block, Linux has destroyed the BIOS environment, and it is not possible to re-gain the contents of the memory block (because Linux did not save it before destroyed it), and so the BIOS will not function intactly.

Some motherboards (which are the so-called "good" ones) have no re-usable memory, thus the BIOS environment will never be destroyed. So on such kind of machines, grub4dos might always be KEXECed smoothly without any trouble.





Also tagged with one or more of these keywords: grub4dos, kexec, keyboard, hang, ubuntu

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users