Jump to content











Photo
- - - - -

Chainloading bootmgr by G4D on GPT style USB Stick fails

grub4dos gpt bootmgr bcd usb stick

  • Please log in to reply
15 replies to this topic

#1 COD11

COD11

    Member

  • Members
  • 63 posts
  •  
    Germany

Posted 05 August 2015 - 12:00 PM

I created a BIOS bootable USB Stick (harddisk style) with 3 GPT-Partitions. Primary bootmanager is GRLDR (GRUB4DOS 0.4.6a 2012-12-05), renamed as "bootmgr". It boots fine on GPT and shows all partitions. When I tried to chainload the original Win7 bootmgr (renamed as "w7mgr") to boot my WIN7 OS on built-in harddisk I got "0x0000000e" error (=The boot selection failed because a required device is inaccessible). Of course I had adapted a local /BOOT/BCD on the USB Stick with "bcdedit" (and "EasyBCD" in a 2nd attempt). I loaded the local BCD hive for inspection to the registry and found out, that the appropriate element contains no drive/partition information of the local drive ( = inaccessible device ?). Does it need it at all ? Is renamed bootmgr the problem ?

 

Is it possible - by any means- to direct "w7mgr" (read as "bootmgr") to the local USB Stick so that it finds the BCD entry which points to "winload.exe" on my harddisk ?



#2 S466531257BOSS

S466531257BOSS

    Member

  • Members
  • 33 posts
  • Location:NIEDERSACHSEN ( Lower Saxony ) , HANNOVER ( Hannoi )
  • Interests:ETC PP ...
  •  
    Germany

Posted 05 August 2015 - 12:39 PM

Can you share your setup as an image ( without the system itself for sure ) or complete steps you have taken, so i am able to duplicate it, then i would fire it up over here to have a look .



#3 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 August 2015 - 02:19 PM

You are attempting to boot that on BIOS (or UEFI+CSM) right?

 

How exactly did you setup the stick?

Hybrid MBR I believe.

 

I would presume that the issue is with the Windows 7 BOOTMGR (that doesn't support the GPT), try with an 8 or 8.1 one instead.

 

There is a whole thread revolving around "tricks" to boot GPT devices on BIOS machines (while not using a Hybrid MBR):

http://reboot.pro/to...in-bios-to-gpt/

and I seem to remember that a similar issue with Windows 7 BOOTMGR was reported in it. :unsure:

 

:duff:

Wonko



#4 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 05 August 2015 - 04:16 PM

Is it possible - by any means- to direct "w7mgr" (read as "bootmgr") to the local USB Stick so that it finds the BCD entry which points to "winload.exe" on my harddisk ?


I don't know a direct solution.
Bootmgr dosn't search boot\bcd at a gpt disk.

Work arround: map the USB Stick to a MBR disk or a floppy.

http://reboot.pro/to...e-7#entry192912

At which partition are located w7mgr and bcd?

Guessed, not tested:
\w7mgr and \Boot\bcd at (hd0,0), the USB stick at boot
Windows at (hd1,0), the internal disk
 
map --read-only --in-situ (hd0,0)+1 (hd0,0)
#no map (hd0) (hd1)
map --hook
root (hd0,0)
chainloader /w7mgr
boot


#5 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 06 August 2015 - 03:54 AM

I don't know a direct solution.
Bootmgr dosn't search boot\bcd at a gpt disk.

Work arround: map the USB Stick to a MBR disk or a floppy.

http://reboot.pro/to...e-7#entry192912

At which partition are located w7mgr and bcd?

Guessed, not tested:
\w7mgr and \Boot\bcd at (hd0,0), the USB stick at boot
Windows at (hd1,0), the internal disk
 

map --read-only --in-situ (hd0,0)+1 (hd0,0)
#no map (hd0) (hd1)
map --hook
root (hd0,0)
chainloader /w7mgr
boot

 

>>> map --read-only --in-situ (hd0,0)+1 (hd0,0)

 

It seems this would make no sense. Usually you want an in-situ map for a logical partition.

 

For primary partitions (hd0,0), (hd0,1), (hd0,2), (hd0,3), you usually do not want an in-situ map.



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 August 2015 - 10:44 AM

>>> map --read-only --in-situ (hd0,0)+1 (hd0,0)

 

It seems this would make no sense. Usually you want an in-situ map for a logical partition.

 

For primary partitions (hd0,0), (hd0,1), (hd0,2), (hd0,3), you usually do not want an in-situ map.

I would guess that the guess by cdob makes sense :) to me (though whether it works or not is of course another thing :ph34r:).

Try reading the above as:

map --read-only -in-situ [the GPT partition (hd0,0)+1] to [the MBR partition (hd0,0)]

Or in plain English, write (in memory only) a partition entry in first slot of the MBR partition table with the location and extents of the first partition in the GPT partition table.

 

The idea is nice :).

 

:duff:

Wonko



#7 COD11

COD11

    Member

  • Members
  • 63 posts
  •  
    Germany

Posted 06 August 2015 - 05:31 PM

You are attempting to boot that on BIOS (or UEFI+CSM) right?

 

On bare AMI BIOS ( about six  years old )

 

How exactly did you setup the stick?

Hybrid MBR I believe.

 

Yes and no, I don't add or change any MBR entries manually or within my slim MBR code, but use an extended INT13 Drive Packet structure within my code ( therefore "hardcoded" ) to load the V(P)BR of 1st GPT Partition to its expected boot location in memory. Since there is no ESP ,  1st GPT partition starts always at 0x040800. If  "GPT-(U)EFI-Boot  ignores all MBR code" is true,  there is nothing to upset a bootmanager.

 

I would presume that the issue is with the Windows 7 BOOTMGR (that doesn't support the GPT), try with an 8 or 8.1 one instead.

 

I think, you are right. I will try it with Win 8.1 BOOTMGR as soon as I have enough time for that .

 

There is a whole thread revolving around "tricks" to boot GPT devices on BIOS machines (while not using a Hybrid MBR):

http://reboot.pro/to...in-bios-to-gpt/

and I seem to remember that a similar issue with Windows 7 BOOTMGR was reported in it. :unsure:

 

I read it  , and this was the cause to experiment with this issue.  I'm always looking for a KISS solution.

And yes, the error is reported in the thread, too.

 

:duff:

Wonko

@cdob

Guessed, not tested:
\w7mgr and \Boot\bcd at (hd0,0), the USB stick at boot
Windows at (hd1,0), the internal disk
 

\w7mgr and \Boot\bcd at (hd1,0), the USB stick at boot

 

Windows at (hd0,0), the internal disk ( Dual Boot: XP on (hd0,0) and Win7 on (hd0,1); BOOTMGR on (hd0,0), BCD and "winload.exe" on (hd0,1) )

 

Mapping and chainloading BOOTMGR on (hd0,0) with GRLDR (renamed as BOOTMGR on USB Stick) works perfectly.

 

Since BOOTMGR on (hd0,0) is also a renamed GRLDR, I could as well have used "root (hd0,0) configfile /menu.lst". 

 

You can switch between all my different "menu.lst"-files with internal menu items ( with heavy use of tag-files, "iftitle" and drive mapping )

 

 

 

My idea was to find a way - independent from the "big" G4D menus - to boot WIN 7 on my harddisk with its own simple (USB Stick) BOOTMGR BCD menu without loosing my present configuration, where I can switch back to my "menu.lst"- chain from the BOOTMGR menu, if I selected a wrong item. It could be a simple rescue tool, if (hd0,0) on the internal harddisk gets corrupted as long as "winload.exe" is found at the right place.



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 August 2015 - 06:22 PM

My idea was to find a way - independent from the "big" G4D menus - to boot WIN 7 on my harddisk with its own simple (USB Stick) BOOTMGR BCD menu without loosing my present configuration, where I can switch back to my "menu.lst"- chain from the BOOTMGR menu, if I selected a wrong item. It could be a simple rescue tool, if (hd0,0) on the internal harddisk gets corrupted as long as "winload.exe" is found at the right place.

 

Well, but then you can (like everyone else) use one of the various "Vista floppy" image variants.

Since you anyway are booting first thing to grub4dos.

If as you say your loader/whatever allows the booted grub4dos to "see" the GPT volume, you can map the whole first GPT partition/volume extents to (fd0) and chainload the (fd0), of course it depends on how big is that volume.

 

Or am I missing something? :unsure:

 

If you want to simplify (actually even completely remove) the menu.lst, besides embedding it in the grldr you can always have a go at the (shameless plug ;)) COSMIAS container concept:

http://reboot.pro/to...-to-g4d-images/

 

:duff:

Wonko



#9 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 06 August 2015 - 09:46 PM

It seems this would make no sense. Usually you want an in-situ map for a logical partition.

Well, it's a bug or feature currently.
Grub4dos does map the GPT partition (hd0,0) to a MBR parition entry (hd0,0).
Bootmgr does find \boot\bcd at virtually MBR disk.
This works well at current grub4dos.

The readme describes
map --in-situ (hd0,4)+1 (hd0)
In my experience this dosn't map to (hd0), but to (hd0,0) always. That's fine for the documented win9x example.

I wonder can --in-situ be expanded?:
given a GPT disk with four partitions.
Request: map the GPT partition to a MBR partition entry.
map --read-only --in-situ (hd0,0)+1 (hd0,0)
map --read-only --in-situ (hd0,1)+1 (hd0,1)
map --read-only --in-situ (hd0,2)+1 (hd0,2)
map --read-only --in-situ (hd0,3)+1 (hd0,3)


#10 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 07 August 2015 - 02:05 AM

cdob, on 07 Aug 2015 - 05:46 AM, said:
Well, it's a bug or feature currently.
Grub4dos does map the GPT partition (hd0,0) to a MBR parition entry (hd0,0).
Bootmgr does find \boot\bcd at virtually MBR disk.
This works well at current grub4dos.

The readme describes

map --in-situ (hd0,4)+1 (hd0)
In my experience this dosn't map to (hd0), but to (hd0,0) always. That's fine for the documented win9x example.

I wonder can --in-situ be expanded?:
given a GPT disk with four partitions.
Request: map the GPT partition to a MBR partition entry.
map --read-only --in-situ (hd0,0)+1 (hd0,0)
map --read-only --in-situ (hd0,1)+1 (hd0,1)
map --read-only --in-situ (hd0,2)+1 (hd0,2)
map --read-only --in-situ (hd0,3)+1 (hd0,3)

As known, the --in-situ switch only virtualize the partition table(and some BPB fields of PBR). It is possible to modify the code and support partition numbers 1, 2, and 3.

EDIT: Just took a look at this code:

else if (grub_memcmp (arg, "--in-situ=", 10) == 0)
      {	unsigned long long tmp;	p = arg + 10;
	if (! safe_parse_maxint (&p, &tmp))
		return 0;
	in_situ_flags = (unsigned char)tmp;
	in_situ = 1;
      }

and see there is an undocumented --in-situ=FLAG usage. Although it was designed by me, sorry, I simply cannot remember what it really does. I will try and find it out again.

EDIT 2: Just find out the flag is used to empty the other 3 partition entries, which is of no use.

EDIT 3: Mappings always create virtual drives, not virtual partitions. BIOS (int13)knows drive numbers, but it does not know of partitions on a drive, and it has no interface/API for the user to access partitions on a drive. So "virtual partitions" is meaningless (at this moment); and we always create virtual drives, possibly with a virtual partition table(in the case of --in-situ). Consequently, if we try to map two or more partitions/files to the same drive number, like this:
 

map --in-situ (hd0,4)+1 (hd0)
map --in-situ (hd0,5)+1 (hd0)
map --in-situ (hd0,6)+1 (hd0)

then only the last one will work.

Finally, look at this:
 

map --in-situ (hd0,0)+1 (hd0,0)
map --in-situ (hd0,1)+1 (hd0,1)
map --in-situ (hd0,2)+1 (hd0,2)
map --in-situ (hd0,3)+1 (hd0,3)

It is acceptable, but the "virtual partition number" is discarded, thus it is equivalent to this:
 

map --in-situ (hd0,0)+1 (hd0)
map --in-situ (hd0,1)+1 (hd0)
map --in-situ (hd0,2)+1 (hd0)
map --in-situ (hd0,3)+1 (hd0)

And so only the last one (of the 4 maps) will take effect.

EDIT 4: It is possible to improve the mappings to support a user-defined (virtual)MBR, conceptually like this:
 

map --in-situ --customized-mbr (hd0,0)/somewhere/a-512-byte-sector-file  (hd0)

But this needs further development. (Anyone really needs  this?)



#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 August 2015 - 10:00 AM

EDIT 4: It is possible to improve the mappings to support a user-defined (virtual)MBR, conceptually like this:
 



map --in-situ --customized-mbr (hd0,0)/somewhere/a-512-byte-sector-file  (hd0)

But this needs further development. (Anyone really needs  this?)

*needs* is a BIG word, to me, but it seems like a really nice idea :) it would be nice to have it, even if it not - strictly speaking - *needed* right now it may become useful before or later.

 

:duff:

Wonko



#12 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 07 August 2015 - 10:51 AM

If it is needed, I think it might be implemented more easily in 0.4.6 by yaya.

 

In 0.4.5, the map slots only support one contiguous address range. So we cannot map 4 entries at the same time for a virtual drive.

 

In 0.4.6, yaya has supported mappings for fragmented files. So I think there must be room for storing the pieces. And that room can be used to store the 4 partition entries in the case of an in-situ map. This way we could avoid using a 512-byte disk sector file.



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 August 2015 - 11:18 AM

If it is needed, I think it might be implemented more easily in 0.4.6 by yaya.

 

In 0.4.5, the map slots only support one contiguous address range. So we cannot map 4 entries at the same time for a virtual drive.

 

In 0.4.6, yaya has supported mappings for fragmented files. So I think there must be room for storing the pieces. And that room can be used to store the 4 partition entries in the case of an in-situ map. This way we could avoid using a 512-byte disk sector file.

As I see it there are no issues with having it in 0.4.6 only :) (and of course there is no hurry for it), but one of  points of the feature "--customized-mbr" (which personally I would shorten to "--custom-mbr") is IMHO that of being able to map an existing 512-byte sector (be it "file" or directly a disk sector).

Again, right now I have no idea for a real-world practical use of the feature, but I "sense" it may be of use *somehow* for "strange" tricks like (say :dubbio:) a form of the "XP Kansas city Shuffle" or some other trick involving disk signature or checksum (or howevers other "areas" of the MBR besides the actual partition table). :unsure:

 

:duff:

Wonko


  • tinybit likes this

#14 Zoso

Zoso

    Silver Member

  • Advanced user
  • 640 posts
  •  
    Isle of Man

Posted 07 August 2015 - 12:44 PM

right now I have no idea for a real-world practical use of the feature, but I "sense" it may be of use *somehow* for "strange" tricks like (say :dubbio:) a form of the "XP Kansas city Shuffle" or some other trick involving disk signature or checksum (or howevers other "areas" of the MBR besides the actual partition table)


I have no idea about it but this sounds very useful "somehow". if nothing else it would seem to allow more options for when some type of barrier or limitation of the current Grub4Dos is reached so it would expand possibilities, no?

the "kansas city shuffle" was a pretty big deal at the time so it seems this is/could be too.

#15 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 07 August 2015 - 01:25 PM

As I see it there are no issues with having it in 0.4.6 only :) (and of course there is no hurry for it), but one of  points of the feature "--customized-mbr" (which personally I would shorten to "--custom-mbr") is IMHO that of being able to map an existing 512-byte sector (be it "file" or directly a disk sector).

Again, right now I have no idea for a real-world practical use of the feature, but I "sense" it may be of use *somehow* for "strange" tricks like (say :dubbio:) a form of the "XP Kansas city Shuffle" or some other trick involving disk signature or checksum (or howevers other "areas" of the MBR besides the actual partition table). :unsure:

 

:duff:

Wonko

 

insightful and deep-going. hopefully someone could be enlightened and help to develop grub4dos in a way.



#16 Zoso

Zoso

    Silver Member

  • Advanced user
  • 640 posts
  •  
    Isle of Man

Posted 07 August 2015 - 02:21 PM

insightful and deep-going. hopefully someone could be enlightened and help to develop grub4dos in a way.

hi tinybit,

I guess it is probably hard for you to get help with development because Grub4Dos is already highly developed so most times what might be a suggestion for development, is already developed. it is not easy to know Grub4Dos full capibilities.

I wonder if it can function like diskcryptor's mbr/bootloader where we have these boot options:
first disk mbr,
first partition with apropriate password,
specified partition,
boot disk mbr,
active partition.

I feel pretty sure it does and I dont have the knowledge to be able to use them but I want to mention it anyway so if it does not have all these options maybe that will help developments.

Diskcryptor is open source, I dont know if its booting capabilities nessesarily need encryption to work or if they can be incorporated with only passwords and not encryption. maybe it is worth looking at (diskcryptor) I think it is abandonware now.

I use it as main bootloader and go from there to either BCD or boot.ini then Grub4Dos. its a complicated set-up because I didnt know any better ways. I mentioned more about this recently to steve6375 here if you are interested: http://reboot.pro/to...rs/#entry194191





Also tagged with one or more of these keywords: grub4dos, gpt, bootmgr, bcd, usb stick

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users