23 replies to this topic

[trueriver]

hi,

1. I can't work out the grub2 commands to chainload back to grldr.

 

What I want to do is to add an option to the boot menu in WattOS (an Ubuntu-derived distro) so  that I can run grub4dos when I want to. The partition with grub4dos is /dev/sda1, formatted FAT32, and contains a valid grldr.

 

It has been bootlaced with 

 

 

bootlace.com --floppy=1 /dev/sda1

 

 

and I have chainloaded into similar partitions in the past (but always from legacy grub, not from grub2)

 

If it is possible to do this, please could someone post the complete grub2.cfg stanza for this. Thanks.

 

2. With a hard drive that has the MBR set up for grub2, I cannot get grub4dos to boot into the grub2 system after installing the grub4dos MBR. I tried

 

 

bootlace.com /dev/sda

 

 

and it offers the choice between old and new MBR.

 

But when I choose the old MBR, it says it is invalid. What happens to the backup of the MBR if you can't use it?

 

Is it possible to do what I want here? If so, how do I save the grub2 MBR so that it remains valid

 

regards,

River~~

Edited by trueriver, 13 February 2013 - 10:40 PM.

[Wonko the Sane]

Wait a minute.

The grub2 MBR (just like the grub4dos MBR) is NOT a MBR.

It is a MBR with a number of sectors appended to it (which are written to a few hidden sectors).

In the case of grub4dos, the MBR is the file grldr.mbr, which is 18 sectors long (or 9216 bytes).

A MBR (a "real" one) is 1 sector or 512 bytes long.

The grldr.mbr has the second sector empty so that you can have it replaced by the "previous MBR" which MUST be a "real" MBR, i.e. 512 bytes long.

Since the GRUB2 MBR is longer than 512 bytes, when you install grub4dos over it, it's first sector will be copied replacing the 00's in second sector.

When you choose previous MBR, the first sector of GRUB2 will be loaded and it won't be able to find the "rest of itself" (as that is actually grub4dos code).

 

But what you want to do is to chainload grub4dos from GRUB2.

 

You know how to load a linux kernel from GRUB2, don't you?

 

Knowing that grub.exe is actually (besides a DOS executable) a Linux kernel could be the missing piece of info:

http://diddy.boot-la...stall_linux.htm

 

Wonko

[cdob]

1. I can't work out the grub2 commands to chainload back to grldr.

At BIOS mode

if [ "$grub_platform" = "pc" ]; then
  menuentry "GRUB4DOS" {
    linux16 /grub2/grub.exe
  }
fi

Adjust the grub.exe path.

[trueriver]

hi Wonko, cdob

 

thanks for the reminder that I can boot via grub.exe, that is a useful fallback in case I can't do it my preferred way

 

However, for now I still want to try to boot from grub2 via grldr not via grub.exe.

 

My reason is that I am wirting a howto for extending the use of the easy2boot for use from an installed linux.

 

The usual download from the easy2boot project comes with grldr and not grub.exe, and it would be good if I can work out how to avoid adding another file to it.

 

My reason for thinking this is possible is that it works from legacy grub or from grub4dos:

 

Preparing a partition on the disk like this

 

bootlace.com --start-sector=1 --floppy=0 /dev/sda1

 

(notice that since my OP I have discovered that I got the "floppy" number wrong, it counts form zero not from 1; and I also discovered I need the --start-sector=1 value to get it to work.

 

Then from grub4dos commandline

 

chainloader (hd0,0)+1
boot

 

works, as does the more verbose version using rootnoverify. However the following in the grub2 commandline fails dismally

 

chainloader (hd0,msdos1)+1
boot

 

It fails with the unhelpful message "disk error" (top left on blank screen). This locks the machine which needs to be power cycled to restart, any keyboard command, including ctrl+alt+del, is ignored

 

What am I missing? Note: I am a complete newbie in grub2. I am sure it is obvious to an experienced grub2 writer... 

 

I am now experimenting with the  assumption that I need to include some "insmod" commands, as the Ubuntu grub.cfg files seem to be absolutely full of them... and will let you know if I get anywhere with that

 

@Wonko,

 

thanks for the explanation of why the backup boot sector fails. 

 

River~~

[steve6375]

If have never used grub2 but found this...

 

(hdn,m) is the partition m on disc n, partition numbers starting with 1, disc numbers starting with 0

http://www.dedoimedo...ers/grub-2.html

[Wonko the Sane]

Yep, the numbering of partitions changed in GRUB2.

http://doc.opensuse....b2.new.features

 

This is an issue even for Linux users (as "GRUB legacy" as well as grub4dos use the "other way").

On the other hand is more "natural" as in Linux they do start from 1.

 

BTW, I seem to remember that GRUB2 can also use menu.lst files (of course only with commands compatible with "GRUB legacy" and not the new commands peculiar to grub4dos and if no grub.cfg is found).

Never actually experimented with that, though, and possibly this feature was removed in more "mature" versions of GRUB2).

 

BUT why:

 

 

chainloader (hd0,msdos1)+1
boot

AFAICR it should be (in GRUB2):

 

 

 

chainloader (hd0, 1)

boot

 

 

or (better as you have the feedback from the root command):

 

 

 

 

root (hd0,1)

chainloader +1

boot

 

 

Wonko

[trueriver]

BUT why:

 

 

AFAICR it should be (in GRUB2):

 

(hey, this forum seems to remove embedded quotes - how can I force it to include them so that questions like this make sense?)

 

I used the form (hd0,msdos1) instead of (hd0,1) because 

 

1. That is what you get shown if you ls to find the partitions on the drive

2. That is what you get offered with tab autocompletion

3. That is what ubuntu use in their scripts

 

The form (hd0,1) does indeed seem to work if typed in expicitly, but it seemed a good idea to me to follow the experts.

 

Trying it instead of the newer form gives the same errors, and indeed the same successes in other examples.

 

Also, it helps me to remember that the counting is different. I am guessing the real difference is that it will provide an error if it is some other kind of partition table.

 

or (better as you have the feedback from the root command):

 

except that the root command does not exist in grub2. There is a

 

 

set root=(hd,msdos1)

 

 

command, but it acts more like rootnoverify (that is it does not seem to complain if you give it a silly value)

 

I will try the menu.lst - but that would surprise me as the grub2 way of doing things is so different and some commands (like root) do not even exist.

 

Regards

 

Edited by trueriver, 15 February 2013 - 10:15 PM.

[Wonko the Sane]

I used the form (hd0,msdos1) instead of (hd0,1) because 
 
1. That is what you get shown if you ls to find the partitions on the drive
2. That is what you get offered with tab autocompletion
3. That is what ubuntu use in their scripts

Well, it is very possible that there is a new "feature".
Last time I tried using the thingy, it had an output similar to this:

 

grub> chainloader (hd0, <tab>
Possible partitions are:
Partition hd0,1: Filesystem type ext2, Label KARMIC, Last mofication time 2009-12-23 04:02:13 Wednesday, UUID 6d6af125-7087-4frb6-afbc-14ddeeb465b8
Partition hd0,2: Filesystem type ext2, Label JAUNTY, Last mofication time 2009-12-25 04:39:45 Friday, UUID 6d6af125-7087-4frb6-afbc-14ddeeb465b8
Partition hd0,3: Filesystem type ext2, Label INTREPID, Last mofication time 2009-12-25 04:39:45 Friday, UUID 6d6af125-7087-4frb6-afbc-14ddeeb465b8
Partition hd0,5: Filesystem type ext2, Label HARDY, Last mofication time 2009-12-28 10:577:17 Monday, UUID 6d6af125-7087-4frb6-afbc-14ddeeb465b8
Partition hd0,6: Unknown filesystem

grub> chainloader (hd0,2)+1
grub> boot

example taken from:

http://members.iinet...e Commands.html

 

Still as far as I know, this makes little sense:

 

 

However, for now I still want to try to boot from grub2 via grldr not via grub.exe.

You want to boot grub4dos, the suggested way to do so is to use grub.exe, and it works normally. (this means that the problem is ALREADY solved).

 

Since grldr can normally be booted from the bootsector of the volume (just like NTLDR or BOOTMGR), I see no issues however in theory  in installing the grub4dos bootsector to that volume.

An example is given here (link previously posted by steve6375):

http://www.dedoimedo...ers/grub-2.html

 

 

So, yes, your entry should be:

 

 

{
menuentry  "Test grldr on dev/sda1"
set root=(hd0,1)
chainloader +1
}

 

To test if there is an issue with the bootsector, chaniload grub.exe from GRUB2 , and from this grub4dos chainload the partition:

 

 

root (hd0,0)
chainloader +1
boot

if it re-cycles to grub4dos the bootsector and grldr are OK.

 

 

Wonko

 

P.S.: JFYI the Owner and Admin of the board found NOT fun "quote pyramids" and in order to avoid them set the board so that this - while still possible - has become more difficult.

http://www.911cd.net...showtopic=22588

http://www.911cd.net...ndpost&p=155361

The fact that this harasses any member of the board attempting to properly quote a previous post of course seems like seen as "collateral damage".

[trueriver]

Well, it is very possible that there is a new "feature".
Last time I tried using the thingy, it had an output similar to this:

grub> chainloader (hd0, <tab>
Possible partitions are:
Partition hd0,1: Filesystem type ext2, Label KARMIC, Last mofication time 2009-12-23 04:02:13 Wednesday, UUID 6d6af125-7087-4frb6-afbc-14ddeeb465b8
Partition hd0,2: Filesystem type ext2, Label JAUNTY, Last mofication time 2009-12-25 04:39:45 Friday, UUID 6d6af125-7087-4frb6-afbc-14ddeeb465b8
...

Mine looks the same, but with the extra msdos after the comma.

My best guess is that this is to cope with other partition types. For example I believe some of the new partition schemes make the entire disk look like a single msdos partition (type=0xee) to discourage fdisk from clobbering them. In that case, (hd0,1) would be ambiguous....

 

You want to boot grub4dos, the suggested way to do so is to use grub.exe, and it works normally. (this means that the problem is ALREADY solved).

fair comment
 

Since grldr can normally be booted from the bootsector of the volume (just like NTLDR or BOOTMGR), I see no issues however in theory  in installing the grub4dos bootsector to that volume.

That is what I was hoping. However the practice seems different (at least with the grub2 shipped with WattOSr6, an Ubuntu derivative).

Yes I started with the code as suggested before I made the OP, and it did not work. And yes, it does chainload nicely from either legacy grub or from another instance of itself, it is just grub2 being too clever. My suspiscion is that the issue is somehow related to grub2 trying to see if the boot sector is "legal" rather than just branching to it and seeing what happens.

Nor did it work with the two insmod lines, nor with the newer syntax for the partition. I was hoping someone would say "oh yes here is this new command you need to add to prevent grub2 doing XXXX".

But nobody is saying that, so I am giving up and will use grub.exe - reluctantly as it would be nice to be able to use the same file for both cases

This is, of course, where OFS would be useful, but it is not robust enough to pass on to others.... do you remember the overlapping file system that you put together manually on a floppy...?

Anyway, thanks both of you for thinking about the question
River~~

[Wonko the Sane]

But nobody is saying that, so I am giving up and will use grub.exe - reluctantly as it would be nice to be able to use the same file for both cases

I wonder how you managed to be wrong even when right :
Giving up is NEVER an option!

Now, knowing that if you use the "normal" 2K/XP bootsector will actually boot NTLDR and that this works also to boot a grldr (BTW if you rename it to ntldr - STRONGLY NOT advised by me):

http://www.911cd.net...showtopic=18031

if you simply hex-edit the NTLDR string in the bootsector AND that someone  wrote a small batch to do that:

http://reboot.pro/to...-alpha-release/

might be of help .
 

This is, of course, where OFS would be useful, but it is not robust enough to pass on to others.... do you remember the overlapping file system that you put together manually on a floppy...?

Sure I do , but it wouldn't prolly help in this case.

 

Wonko

[trueriver]

I wonder how you managed to be wrong even when right :
Giving up is NEVER an option!

hmmmm.
It is more a case that I have reached the point where any likely kludge is worse than just installing the extra file.

Now, knowing that if you use the "normal" 2K/XP bootsector will actually boot NTLDR and that this works also to boot a grldr (BTW if you rename it to ntldr - STRONGLY NOT advised by me) ...

see what I mean? Installing a win bootloader on a linux machine just to boot grldr is a terrible kludge. To be fair, I don't think I explained it is a linux-only box: g4d is being used as part of the easy2boot suite, not for its original purpose of interfacing between win and lin

But suppose it *was* a Win machine, the suggestion you make is then obsolete. Sure, Tinybit deliberately called GRLDR that so you could do that kludge (post somewhere bootland around 2009). But soon after the Chinese hackers found a better way. You can add an entry to the Win menu to load GRLDR. This can be done for either NTLDR or BOOTMGR. I have done this before and it definitely worked with g4d 0.4.4

But it is a Linux box, so if anything extra needs to be installed, better to make it grub.exe.

Re OFS:

 
but it wouldn't prolly help in this case.

Assuming it is still true that grub.exe is contained within grldr (true for 0.4.4, not sure about more recent versions) the OFS hack would be to fake grub.exe in the FAT partition. Then from GRUB2

insmod part_msdos
insmod fat
linux16 (hd0,msdos1)/grub.exe

The key point being that unlike legacy grub, grub2 will read fat partitions providing you load the module that tells it how.

By the way, in grub2 commandline again

chainloader (hd0,msdos1)/grldr

gives "Signature error", whereas

chainloader (hd0,msdos1)+1

gives "disk error"

The first of these messages suggests that grub2 is being over protective.

Thanks for your thinking
River~~

[Wonko the Sane]

But suppose it *was* a Win machine, the suggestion you make is then obsolete. Sure, Tinybit deliberately called GRLDR that so you could do that kludge (post somewhere bootland around 2009). But soon after the Chinese hackers found a better way. You can add an entry to the Win menu to load GRLDR. This can be done for either NTLDR or BOOTMGR. I have done this before and it definitely worked with g4d 0.4.4

Yes, you didn't mention it was a Linux only machine, but no, grldr was designed from the very beginning to be loaded from BOOT.INI, the practice of misnoming it came from Spacesurfer and it is frowned upon by both me (because of the possible confusion it may create) and by the grub4dos Authors probably because they felt that this feature could have been broken by later versions, which actually happened, so that there is a reference on how to rename grldr in readme_grub4dos.

 

But, even if it is a Linux machine, you can still TRY it as this would be a confirmation that the issue is omehow withing GRUB2 and not *somewhere- else.

And it is not about installing a "win bootloader", it is about using the windows bootsector code.

As you may well know, Linux uses normally only the BPB part of the bootsector.

 

Wonko

[trueriver]

...
But, even if it is a Linux machine, you can still TRY it as this would be a confirmation that the issue is omehow withing GRUB2 and not *somewhere- else.

but I know it is in GRUB2. If g4d and legacy grub both do it ok, and grub2 doesn't, the difference is in grub2, surely?

As I said before, my suspicion is that the "issue" is deliberate - grub2 is doing some kind of overhelpful sanity check.

Either that, or it is an issue with 16bit/32bit code (like the difference between linux and linux16 in grub2)

And it is not about installing a "win bootloader", it is about using the windows bootsector code.

Point taken.

But even that would still need to be installed somehow, on to a drive that Windows refuses to make bootable... (and that is another story, which I will maybe tell another time)

[Wonko the Sane]

but I know it is in GRUB2. If g4d and legacy grub both do it ok, and grub2 doesn't, the difference is in grub2, surely?

As I said before, my suspicion is that the "issue" is deliberate - grub2 is doing some kind of overhelpful sanity check.

No. (which means it is possible, but till now not really verified/checked)

From what I got the bootsector code from grub4dos, correctly written to the partition bootsector

(to test this, you just load from GRUB2 grub.exe and from it you chainload the partition bootsector).

is not chainloaded successfully by GRUB2.

The test would determine if the issue is GRUB2 with the specific grub4dos bootsector code, or it is GRUB2 with *any* bootsector code.

 

But even that would still need to be installed somehow, on to a drive that Windows refuses to make bootable... (and that is another story, which I will maybe tell another time)

Owww, comeon.
It is a bunch of bytes that you write to a single sector (leaving the BPB data as is or - at the most - changing the OEM name).

 

With the result of this test, we may go forward .

 

See this example (related to the MBR code, and an "overhelpful" BIOS instead):

http://reboot.pro/to...-i-have-found/ 


Wonko

[trueriver]

but I know it is in GRUB2. If g4d and legacy grub both do it ok, and grub2 doesn't, the difference is in grub2, surely?

 
 
Let me summarise the tests I did before I made the OP.
 
 

chainload into                      from grub4dos                            from grub2   

g4d in mbr                                ok                                      ok 
g4d in partition                          ok                                   **fails** 
grub2 in mbr                              ok                                      ok 
grub2 in partition                        ok                                      ok

  That's what I mean when I say grub2 works except when you ask it to chainload into a grub4dos partition.   What is not certain, and is only a guess, is that this failure is a side effect of deliberate signature checking. The evidence for that guess is the error message "invalid signature" in the direct form of the command (chainloader (hd0,msdos1)+1
 
 
Now I have detailed exactly what I meant, do you still think there is any point trying to boot via a hand entered windows boot sector? What new info would that give me?

Edited by trueriver, 17 February 2013 - 06:33 PM.

[Wonko the Sane]

NOW, it is perfectly possible (not that it actually represents what is happening, only what is possible):

1. the result of the bootlace.com command issued *somehow* wrote *something* that is ONLY compatible with grub4dos
2. the result of the bootlace.com command issued was actually a perfectly valid bootsector that can be booted by ANY MBR code as soon as the partition has been made active
3. the GRUB2 is NOT compatible with the *something* that has been written
4. the GRUB2 is NOT compatible with *any* otherwise perfectly valid bootsector that uses grub4dos bootsector code (because it is overhelpful/checking signatures)
5. the GRUB2 is NOT compatible with *any* perfectly valid bootsector

Out of the above 5 logical possibilities you decided that the right ones are  #2 and #4, but you did not perform (or omitted to post results of) the tests needed to make sure that this is what actually happened.

 

These tests include:

• verify that what is written to that partition is actually a valid bootsector (BPB)
• verify that what is written to that partition is actually a valid grub4dos bootsector (code)
• try using another bootsector code (provided that the BPB data is correct)

If you dd the first sector of that partition to a file, compress it in a .zip file, upload it somewhere I can get it, I may be able to check it's contents and provide you a way (if needed) to test an alternate bootsector.

 

 

Wonko

[steve6375]

Not sure if it helps, but there was an issue with grubinst and the way it modified the PBR. Some versions of DOS need to see a number like 5.1 (if FAT32) near the beginning of the PBR. Older versions of grub4dos (grubinst) destroyed this. The latest chenall grub4dos fixes this. Maybe you could look at the PBR and see what it has. Latest version has GRLDR5.1 (from memory).

[Wonko the Sane]

.... and since Steve6375 mentioned the issue, some info on the meaning of the OEM in BPB:

http://homepage.ntlw...name-field.html

and how it has been largely misused historically

 

Other "strange" things listed in this topic:

http://reboot.pro/to...or-usb-booting/

 

The specific issue has been discussed here:

http://reboot.pro/to...rub4dos-to-pbr/

 

Wonko

[trueriver]

NOW, it is perfectly possible (not that it actually represents what is happening, only what is possible):

• the result of the bootlace.com command issued *somehow* wrote *something* that is ONLY compatible with grub4dos
• the result of the bootlace.com command issued was actually a perfectly valid bootsector that can be booted by ANY MBR code as soon as the partition has been made active
• the GRUB2 is NOT compatible with the *something* that has been written
• the GRUB2 is NOT compatible with *any* otherwise perfectly valid bootsector that uses grub4dos bootsector code (because it is overhelpful/checking signatures)
• the GRUB2 is NOT compatible with *any* perfectly valid bootsector

Out of the above 5 logical possibilities you decided that the right ones are  #2 and #4, but you did not perform (or omitted to post results of) the tests needed to make sure that this is what actually happened.

 

 

aside: Forum issue:

 

For some reason your post renders as a list with no numbers and no bullet points, even though it is a perfectly good <ol> tag which unless I am going totally senile is an "ordered" (numbered) list.

 

Equally bizarrely, the numbers do appear when it is quoted.

 

This effect is the same in Firefox, Chromium, and Seamonkey, so it not just a single browser issue.

 

But anyway, back to the boot related discussion...

 

If 2 was the idea that its a "perfectly valid bootsector that can be booted by any MBR", no I never claimed that at all.

 

My disk does not have any standard MBR code: the "MBR" is the code to load either grub2 or grub4dos. All the chaining described in this thread has been done from one or other of those. Sorry if I did not make that clear. I have no idea what would happen if I did try to load the bootlaced PBR from a true MBR, nor the grub2 PBR as installed by grub-install. So I did not decide anything about no 2.

 

Clearly no 3 is correct: GRUB2 is NOT compatible with whatever it was that bootlace wrote. This has been tested exactly by me.

(Others may or may not be correct as well, but 3 certainly.) No further tests are needed to believe 3.

 

No 4 I said was a "guess", and the reason about an overhelpful validity check I described as a "suspiscion".  I never claimed to "make sure" of anything except 3. Yes, tests could clarify this, but you have not said anything that makes me feel it is worth doing those tests.

 

When the tests get harder than the alternative fix (linux16 grub.exe) which I have already got working, then there seems to be no point continuing with them, surely???? If these results help someone else to debug either grub* then that is great, and they can continue the tests where I left off.

 

And it would be intereting to know the answer of why it did not work the way I expected, but not so interesting as some other things I can do with the time.....

Edited by trueriver, 17 February 2013 - 10:08 PM.

[trueriver]

... The latest chenall grub4dos fixes this. ...

 

ummm, is that version 0.4.5c ? That is the latest I have ?

[steve6375]

use a 2012 version - google for chenall grub4dos...

[trueriver]

use a 2012 version - google for chenall grub4dos...

yes I did, which is when I got confused.

I've got the 0.4.5c with the latest 2012 date, which is the one used in the tests referred to above, not least as it is the same version as came in my Easy2boot download.

But there is also a 0.4.5c with a 2013 date, and some 0.4.6 with 2012 dates that seem to be mainly developmental and seem to predate the latest 2012 0.4.5c.

But it is now becoming academic, as I'm going with the "official" solution of using grub.exe which works without problems. So there is no need to clarify further, Thanks again,

River~~

edit:

It would be nice if someone could post (here or elsewhere on the web) a definitive list of various grub4dos versions. Google does not seem to know of one, cos I looked. It seems to me (and I may be wrong) that it is in a state where different versions are slightly diverging. This is not so much "forking" as :wink: "forking confusing".

Edited by trueriver, 18 February 2013 - 11:13 AM.

[Wonko the Sane]

When the tests get harder than the alternative fix (linux16 grub.exe) which I have already got working, then there seems to be no point continuing with them, surely???? If these results help someone else to debug either grub* then that is great, and they can continue the tests where I left off.

 

And it would be intereting to know the answer of why it did not work the way I expected, but not so interesting as some other things I can do with the time.....

Well, you are giving up , that as said is NOT an option (meaning that it is one, but I had greater expectations from you ).

 

And, NO §@ç#ing need to google for chenall grub4dos, the addresses are clearly stated in the Grub4dos sticky in the grub4dos forum:

http://reboot.pro/forum/66-grub4dos/

http://reboot.pro/topic/14-grub4dos/

and anyway, here:

http://code.google.c.../downloads/list

 

Wonko

[trueriver]

I spent some of last night thinking about this topic. Not how to get the grubs to work together (that is solved), nor how to get chainloader to work as I think it should (which I do not have enrgey to take further), but about *why* I expect chainloader in one product to be able to run something if chainloader in another product does.

I think this deserves a separate thread, like this one here.