Jump to content











Photo
- - - - -

Map MBR-style-disk on GPT partition

gptmbr map driver

  • Please log in to reply
28 replies to this topic

#1 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 27 August 2014 - 02:57 PM

The official GPT specification lists a partition type with a peculiar description :

Partition containing a legacy MBR | 024DEE41-33E7-11D3-9D69-0008C781F39F


A better description from the gpart manual :

mbr | A partition that is sub-partitioned by a Master Boot Record (MBR). This type is known as "!024dee41-33e7-11d3-9d69-0008c781f39f" by GPT.


More details were only obtained from FreeBSD mailing list archive :

Yes. This is a partitions-inside-a-slice configuration, ...


Basically it means that the GPT partition contains a full MBR disk in it... Intended to be mounted as a separate virtual device. It was envisaged that non-GPT-supporting OSes can be booted from such a mapped virtual HDD.

I think it'll be quite easy to make such a mapping module for boot managers like Grub/Grub4dos, as well as a driver for Windows and perhaps Linux... Can be useful both for booting and maybe other things...

So does any of the existing drivers like FileDisk, FiraDisk, WinVBlock, etc. have support for this?

What say @Sha0?

#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 August 2014 - 03:16 PM

The official GPT specification lists a partition type with a peculiar description :

Which - just for the record - is the type "EF01" in gdisk:

http://reboot.pro/to...o-gpt/?p=186493

http://gdisk.sourcea...8cc_source.html

 

:duff:

Wonko



#3 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 September 2014 - 11:54 PM

So does any of the existing drivers like FileDisk, FiraDisk, WinVBlock, etc. have support for this?

Well plans for functionality like Linux device-mapper are still in place for WinVBlock, but the speed of development has nearly ground to a halt.

In GRUB4DOS, you can indeed map a virtual disk from a contiguous range of sectors on a physical disk. This mapping is certainly used by WinVBlock. So you can use such partitions-as-disk-images right now. But the last I checked, GRUB4DOS didn't have GPT knowledge, although that's possibly changed, now.

#4 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 02 September 2014 - 11:02 AM

Interesting, I shall definitely be trying it out... because Grub4Dos does support GPT now.

But your intro post http://reboot.pro/to...8168-winvblock/ seems to list Grub4Dos disks under RAMdisks... Does that mean the whole time it will exist in memory?

That would be less than optimal, since people might want to use a large GPT partition for an MBR disk image.

Edit : Mistaken. Also exists under FileDisk category.

Edited by milindsmart, 02 September 2014 - 11:12 AM.


#5 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 01:09 PM

[...]In GRUB4DOS, you can indeed map a virtual disk from a contiguous range of sectors on a physical disk. This mapping is certainly used by WinVBlock. So you can use such partitions-as-disk-images right now. But the last I checked, GRUB4DOS didn't have GPT knowledge, although that's possibly changed, now.


Facing some trouble booting windows from an MBR disk in a GPT partition, after mapping it to (hd2) using Grub4Dos.
 
The arrangement : 
GPT disk 13000MB, Grub2 MBR
 
5 partitions, of which relevant are :
  • gpt2 : BIOS boot partition for Grub2
  • gpt3 : FAT partition holding Grub2, Grub4dos files.... no bootsector
  • gpt4 : embedded MBR disk
  • gpt5 : NTFS Windows partition
MBR disk 80MB : standard MS MBR, 1 partition, holding bootmgr+BCD
 
I boot to Grub4dos using
menuentry "Grub4dos" {
    
    insmod part_gpt
    set root=(hd0,gpt3)
    linux16 /grub4dos/grub.exe
}
It boots into Grub4dos. Still not being used to boot.ini, I use the shell to type in and get the following :
The first 2 lines are 
grub> map (hd0,
and the response when I pressed TAB, saying "the possible partitions are :" or something to that effect.
The rest is in the attached image. I could not interpret the message after mapping very well.... Could that be the problem?
 
then I typed "boot" + enter, but I got bootmgr error :
File : \Boot\BCD
Status : 0xc0000001
Description : An error occurred while attempting to read the boot configuration data
What's going wrong? If it could boot from a ramdrive such as memdisk or wimboot (see http://reboot.pro/to...e-3#entry186400 and previous posts), then why not from grub4dos direct mapping?
 
An aside : I had a false start when it booted, but that was because the actual VHD whose image I had dumped into the partition was still attached to the VM. Needless to say, the signatures are exactly the same. I recall another thread around here doing just this kind of fooling windows through identical disk signature of image and real device, can't recall.

Attached Files



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 September 2014 - 02:30 PM

Which Windows OS is the BOOTMGR?

Which EXACT verison of grub4dos is it?

 

There is NO boot.ini used in grub4dos, maybe you mean menu.lst, but as already said when experimenting is a good thing that you use command line.

 

What we have been doing on the other thread, had you missed it, was finding out that the BOOTMGR (at least the one form Windows 7) does NOT find a BCD of a grub4dos mapped drive (hard disk drive, i.e. (hdn)) UNLESS it is mapped to a (fdm) device:
http://reboot.pro/to...o-gpt/?p=186471

 

This doesn't happen with NTLDR and BOOT.INI (because NTLDR "trusts" the info of the temporary grub4dos mappings) but happens with BOOTMGR (both with BOOT.INI and \boot\BCD) because evidently the BOOTMGR rechecks the real partition table (that is NOT there) and thus fails.

 

In other words this result was expected.

 

About the "warning" you had, you are providing not enough details on the EXACT[1] partitioning of the device to give you any assistance.

The 576,384 sectors correspond to 295,113,728 bytes, i.e. about 295 Mb, whilst the 163,840 make 83,886,080 bytes, i.e. the "right" 80 Mb roughly, but in any case that is a WARNING ( NOT an ERROR) :).

 

As "generic" advice, you were given the hint that you could try reproducing an already detailed experiment:

http://reboot.pro/to...o-gpt/?p=186656

before attempting variations to it, as while doing this you would get more familiar with the tools involved.

 

The idea being "baby steps" or "learn to walk before starting running", though of course you are perfectly free to start running, do not be surprised if you fall (it is anyway another good way to learn :), though possibly only seemingly faster ...).

 

 

:duff:

Wonko

 

[1]EXACT in this context means sizes detailed to the BYTE or sector number AND either a copy of the partition entries as seen in a tool like gdisk or an exact, detailed report on how (with which tools, with which settings, etc.) the partitions were made.



#7 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 02:49 PM


Exact partition table (can determine partition sizes from this I hope?)

I:\Software\gdisk-windows-0.8.8>gdisk 1:
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk 1:: 26624000 sectors, 12.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1FCA4FA6-2862-4C61-995D-B3CE5991350C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 26623966
Partitions will be aligned on 2048-sector boundaries
Total free space is 518077 sectors (253.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   0700  Windows Boot
   2          206848          210943   2.0 MiB     EF02  BIOS Boot
   3          210944          415743   100.0 MiB   0700  Boot Tools
   4          415744          579583   80.0 MiB    EF01  Embedded mbr disk with

   5         1091584        26619903   12.2 GiB    0700  Windows 7 OS

Command (? for help):

Exact Grub4Dos version : grub4dos-0.4.5c-2014-09-05, same as the one that you pointed me to on the G4D thread.

 

To be honest, I still don't understand exactly what you did in that post... certainly didn't see the conclusion that (hdx) doesn't work but (fd0) does.

 

And I have no idea why 295MB is coming up. The only thing I can suggest is perhaps the 250MB unallocated space after partition no. 4 (as in the above gdisk output) has got something to do with it.

 

There seems to be no escape for bootmgr at all : it uses INT 13 callbacks which HAVE to respect G4Ds mappings, and similar things have worked with memdisk and wimboot. Are you saying that the difference is that I'm using a HDD image now rather than a (Super)Floppy? Why would it suddenly get picky? What additional check CAN it do to discover the deception?



#8 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 02:53 PM

AHA!!!! it worked with mapping (hd0) to (hd1) and (hd1,3) to (hd0) :)

 

And a curious aside as a bonus : Windows recognized gpt1, which, containing bootmgr and BCD, is very similar to the 80MB drive just described here, as the "System" drive!

 

So Windows is trying to be smart here :) In a while this will go on the other thread :)

 

But as far as this thread is concerned, the next step is to install WinVBlock on this Windows and see if it picks up the mapping. If it does, will it still recognize the wrong bootmgr drive as the "System" partition? Or the memmapped one? Find out, in the NEXT episode of Boooot Mgr Z (a play on the Cartoon Network DragonBallZ end-of-episode enticer)  :punk:



#9 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 03:28 PM

What we have been doing on the other thread, had you missed it, was finding out that the BOOTMGR (at least the one form Windows 7) does NOT find a BCD of a grub4dos mapped drive (hard disk drive, i.e. (hdn)) UNLESS it is mapped to a (fdm) device:

http://reboot.pro/to...o-gpt/?p=186471

 

In other words this result was expected.

 

[...]

As "generic" advice, you were given the hint that you could try reproducing an already detailed experiment:

http://reboot.pro/to...o-gpt/?p=186656

before attempting variations to it, as while doing this you would get more familiar with the tools involved.

 

The idea being "baby steps" or "learn to walk before starting running", though of course you are perfectly free to start running, do not be surprised if you fall (it is anyway another good way to learn :), though possibly only seemingly faster ...).

 

I intended to, actually, but I (now) have only one image, and I was loathe to duplicate 13GB and do these experiments :( I'm more lazy than reboot.pro threads indicate :D Plus, I only recently (about 7 hours ago) got a windows version of "dd", and dsfok was refusing to handle \Device\HardDiskm\Partitionn links (and every other variation I tried). Mounting VHDs in linux is irritating still with kpartx, though not as bad as having to do it in a VM as in the case of VMDKs.



#10 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 September 2014 - 03:35 PM

Very good. :)

 

As a matter of fact it does make sense, since you (hd1,3) contains an actual "real" MBR (I missed this : :blush: ), i.e. if we are allowed a "pseudo definition" your boot volume is "(hd1,3,0)" and is actually mapped to "(hd0,0)".

 

The "warning" you had earlier cannot still be explained, can you post the partition table view of the "80 Mb" MBR disk, actually that of the image of it that you inserted as (hd1,3).

 

About dsfok, you actually don't have *any* other access if not \\.\PhysicalDrive and \\.\LogicalDrive, but this is pretty much *normal* and allows AFAIK to normally access *anything* under windows. (OT, but I wonder why exactly do you want/need a different access)

 

JFYI, a good (I hope) list of dd ports to windows is here:

http://reboot.pro/to...uest-for-ddexe/

 

:duff:

Wonko



#11 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 03:56 PM

As a matter of fact it does make sense, since you (hd1,3) contains an actual "real" MBR (I missed this : :blush: ), i.e. if we are allowed a "pseudo definition" your boot volume is "(hd1,3,0)" and is actually mapped to "(hd0,0)".

Yeah exactly, (hd1,3,0) makes a lot of sense :)

The "warning" you had earlier cannot still be explained, can you post the partition table view of the "80 Mb" MBR disk, actually that of the image of it that you inserted as (hd1,3).

Attached.

I notice now, that it's not 1MB aligned. I have no idea why, I created this (rather it's predecessor) in windows 8.1 disk management.

About dsfok, you actually don't have *any* other access if not \\.\PhysicalDrive and \\.\LogicalDrive, but this is pretty much *normal* and allows AFAIK to normally access *anything* under windows. (OT, but I wonder why exactly do you want/need a different access)

Well I needed to dump the image on to the ef01 partition... I had to first delete, remake the partition, assigning a letter, after which I was able to use \\.\r: syntax to dump the data using dsfok, after which I changed the partition type ID to ef01, after which the drive letter disappeared. I could not assign a letter after the partition ID was changed, and could find no other means to get access to the raw sectors in the partition.
I maintain still that \Device\Harddisk0\Partition4 or \\.\PhysicalDrive0\Partition4 is better than \\.\r: . This mixes up volumes and partitions yet again.

Attached Files



#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 September 2014 - 04:25 PM

I notice now, that it's not 1MB aligned. I have no idea why, I created this (rather it's predecessor) in windows 8.1 disk management.

Well, that is "normal", the alignment "advised" (actually forcefully implemented) is not on Mb, but rather of cluster multiples.

And 128 is good enough. :)

 

Hint ;):

Check this key in your Registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VDS\ALIGNMENT

 

Then re-read (this time attentively ;)) this post:

http://reboot.pro/to...o-gpt/?p=186428

 

The data in your 80 Mb hard disk MBR seems fine.

 

What about the PBR?

 

Maybe in your attempts you made a "queer" extension for the volume?

 

BTW, it is possible (since grub4dos support for GPT is experimental) that it is actually a parsing issue with grub4dos itself. :w00t: :ph34r:

 

Since it is a warning (and not an error) and since you are not going to read or write on LBA bigger than what is actually mapped, the 163,840, I see no issues in putting this - at least temporarily - aside as it seems like irrelevant for the rest of the experiments.

 

OK, about accessing the "(hd1,3,0)" volume through a drive letter, I could give you a way (which you probably won't like :dubbio:, but anyway :whistling:... )

  1. Open the disk in a hex editor
  2. Change the "protective MBR entry for the GPT" ID from EE to 05 :w00t: :ph34r:
  3. Go to sector 1 and write in first partition entry (which is outside the GPT header), offset 446, a partition entry pointing to the actual volume AND write a 55AA as last bytes on the sector

 

What you have just done is more or less the "reverse" of what grub4dos partnew command does, you have mapped a volume as "logical volume inside extended".

From this point on, you will be able, by "flipping" between EE and 05 in the MBR partition entry, to access the same volume as GPT or MBR (and - at least under Windows 7 - when the partition type is EE the changed bytes on sector 1 will be ignored, i.e. the disk will still be seen as GPT) 

 

But really if you use \\.\Physicaldrive access, you can use DSFOK dsfi or dsfo fine, as long as you specify the correct offset in bytes (the \\.\Physicaldrive is the *whole* thing).

 

:duff:

Wonko



#13 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 08:26 PM

And Success! After some struggling, as Sha0 said, I installed WinVBlock, and it now captures the mapped drive as a separate drive viewable in disk management.... Perfect! It is recognized as a system drive too.

 

If only it was a signed driver, it could be distributed and people would get used to loading partitions-in-a-slice configuration. I mean, if every single bootable UEFI CD/DVD relies on an embedded FAT partition outside the ISO filesystem but within the physical area of the CD/DVD. why can't every computer be able to infinitely dig in into all nested partitioning arrangements? It's too useful and simple not to be used.



#14 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 08:31 PM

Wonko the Sane, on 06 Sept 2014 - 9:55 PM, said:
Check this key in your Registry:
Then re-read (this time attentively ;)) this post:

Oh haha now I remember, the key values telling how much space to leave before 1st partition depending on how big the drive is...

Wonko the Sane, on 06 Sept 2014 - 9:55 PM, said:
What about the PBR?
Maybe in your attempts you made a "queer" extension for the volume?

queer extension for the volume? remember, the error comes before the filesystem is recognized.

Wonko the Sane, on 06 Sept 2014 - 9:55 PM, said:
BTW, it is possible (since grub4dos support for GPT is experimental) that it is actually a parsing issue with grub4dos itself. :w00t: :ph34r:
Since it is a warning (and not an error) and since you are not going to read or write on LBA bigger than what is actually mapped, the 163,840, I see no issues in putting this - at least temporarily - aside as it seems like irrelevant for the rest of the experiments.

Yeah good chance its a bug. Maybe you could call Chenall or Tinybit to have a look? :)

Wonko the Sane, on 06 Sept 2014 - 9:55 PM, said:
But really if you use \\.\Physicaldrive access, you can use DSFOK dsfi or dsfo fine, as long as you specify the correct offset in bytes (the \\.\Physicaldrive is the *whole* thing).

It's dangerous and error-prone and laborious to use dd with offsets. I prefer to let software do that part, seriously. What's the problem with implementing \Device\Harddisk1\Partition4 syntax for device filenames anyway? It's very standard now, and well documented.

#15 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 07 September 2014 - 06:13 AM

OK, about accessing the "(hd1,3,0)" volume through a drive letter, I could give you a way (which you probably won't like :dubbio:, but anyway :whistling:... )


  • Open the disk in a hex editor
  • Change the "protective MBR entry for the GPT" ID from EE to 05 :w00t: :ph34r:
  • Go to sector 1 and write in first partition entry (which is outside the GPT header), offset 446, a partition entry pointing to the actual volume AND write a 55AA as last bytes on the sector
What you have just done is more or less the "reverse" of what grub4dos partnew command does, you have mapped a volume as "logical volume inside extended".
From this point on, you will be able, by "flipping" between EE and 05 in the MBR partition entry, to access the same volume as GPT or MBR (and - at least under Windows 7 - when the partition type is EE the changed bytes on sector 1 will be ignored, i.e. the disk will still be seen as GPT)


This will however, make the current "sectors before" on the partition invalid - it currently has sectors before as 128, which fits in with the fact that the reference point is the beginning of the embedded MBR disk. This way needs the volume to have "sectors before" as measured from the beginning of the containing (GPT) disk, which is far larger. They cannot coexist.

#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 September 2014 - 10:10 AM

This will however, make the current "sectors before" on the partition invalid - it currently has sectors before as 128, which fits in with the fact that the reference point is the beginning of the embedded MBR disk. This way needs the volume to have "sectors before" as measured from the beginning of the containing (GPT) disk, which is far larger. They cannot coexist.

Sure :), but "sectors before" are NOT really-really needed, for normal operations (mounting) they are needed for booting, as a matter of fact any logical volume inside extended is created with "wrong" sectors before, and this is the reason why they are not bootable and the reason why we "correct" them ;) to make a logical volume inside extended bootable:

http://www.goodells.net/multiboot/

http://www.goodells....ot/ptable.shtml

 

:duff:

Wonko



#17 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 07 September 2014 - 02:22 PM

Is it? What if Windows notices the discrepancy and "fixes" it? :D

Now that I have done this with Grub4Dos and WinVBlock, what's the next step? You'd be surprised how difficult it is for tools to mount a single partition, while they happily mount files. Got to change that.

I don't know about the other filedisk drivers... e.g. firadisk, etc. Can you tell me which others are suitable for this?

#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 September 2014 - 02:42 PM

Is it? What if Windows notices the discrepancy and "fixes" it? :D

It won't rest assured. :)

But if you think about it a bit you can make the 128 sectors before "right" in both cases. :w00t: 

 

What happens IF instead of making the first logical volume entry pointing to "(hd1,3,0)" in LBA1, you use the second entry, pointing it to the MBR of your "(hd1,3)"? :dubbio:

Isn't any EMBR actually a MBR but with only two entries max in the partition table? :whistling:

 

About ramdisks/fiedisks, the usual approach is try winvblock first and if it does not work, then try firadisk (or viceversa, try firadisk first and if it doesn't work, use winvblock instead).

 

The point here is not about filedisk/ramdisks and their "level of hook" in the Windows OS (as it was with the IMDISK issue) the point is "filedisk/ramdisk" that can "hook" the grub4dos mapping.

 

AFAICR/AFAIK firadisk and winvblock are the only ones with this feature and traditionally the one and/or the other has always worked fine.

 

Or are you after "collecting" ramdisks/filedisks? :dubbio:

 

I believe that another number of ramdisk/filedisk drivers may be used to this effect, but you would have to set the parameters (like location, extents, drive letter, etc.) by "hardcoding" them inside thwe Windows OS, usually in the Registry, the difference is that Winvblock or Firadisk can receive the parameters from the grub4dos "on the fly".

 

:duff:

Wonko



#19 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 07 September 2014 - 07:38 PM

But if you think about it a bit you can make the 128 sectors before "right" in both cases. :w00t:
 
What happens IF instead of making the first logical volume entry pointing to "(hd1,3,0)" in LBA1, you use the second entry, pointing it to the MBR of your "(hd1,3)"?   :dubbio:
Isn't any EMBR actually a MBR but with only two entries max in the partition table? :whistling:

This is actually a brilliant idea! I realized what you meant seconds before I read it (read: too late, I've been fiddling with this stuff for months now), that the extended partition is a *very* convenient container, same as ef01, in this context :)

So how it would work is, I create an overlay MBR partition table, with the only actual bytes being in the entry 1, which points to the embedded MBR disk. Everything else will fall in place just like that :) For protection of the rest of the data, instead of being unallocated in this overlay, make the before, and after 0xEE partitions. Then I'll make a script to toggle the partition table. Right?

I think this is precisely the kind of brilliant hack, like disk geometry translation, hybrid MBRs, and (BIOS+EFI+Mac) x (CD/DVD+USB) compatible installation images, that kept people from finding robust solutions to serious problems :)

About why I asked about other filedisks, I'm looking beyond Grub4dos-created virtual disks. I'm looking for a standalone windows driver that auto-probes-for and automounts embedded MBR disk (ef01) data as a separate virtual disk. The same as WinVBlock, but without needing to pick up from Grub4Dos. In other words, I want to make full use of one of the only three GPT partition type IDs in the spec :)


Edited by milindsmart, 08 September 2014 - 05:19 AM.


#20 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 07 September 2014 - 07:49 PM

Coming to think of it, are you getting the feeling that Hybrid MBRs are probably the crudest ways of dealing with GPT/MBR incompatibilities around? I mean seriously, they couldn't come up with ANYTHING better? Why were they so unimaginative as to not think about Virtual Hybrid MBRs? How could they miss the possibility of a WinVBlock, with a selectable GPT partition? Or this (see above post) solution?

#21 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 07 September 2014 - 08:31 PM

How could they miss the possibility of a WinVBlock, with a selectable GPT partition? Or this (see above post) solution?

Could be something about the chronological order of events and expectations yielded by compliance with standards. (U)EFI and GPT certainly go together, but BIOS (like GRUB4DOS uses) is an older scenario. Mish-mashing is fun! :)

#22 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 08 September 2014 - 05:24 AM

Yeah that's definitely there, but they could have implemented something similar then itself. Or is it that the entire concept of mapping partitions and files into memory at boot time was just not thought of at that time? But as mentioned above, El Torito does exactly this, and was written long ago, much before GPT.

 

So I want some ideas, esp by Sha0 : what should I pick as the starting point to make a simple driver to automount all embedded MBR disk images in GPT partitions? Windows or otherwise, whichever is easier.

 

I have zero experience in driver development, but I've been wanting to try, and this project seems ideally suited in that it is very simple in concept.



#23 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 September 2014 - 08:57 AM

So how it would work is, I create an overlay MBR partition table, with the only actual bytes being in the entry 1, which points to the embedded MBR disk. Everything else will fall in place just like that  :) For protection of the rest of the data, instead of being unallocated in this overlay, make the before, and after 0xEE partitions. Then I'll make a script to toggle the partition table. Right?
 

Yep :).

The bad news are that you can have ONLY one partition in the (hd1,3) MBR (i.e. the "(hd1,3,0)", the good news are that most probably you can use the second partition entry in the (hd1,3) MBR to point to another (fake) EMBR (into which you can map another of the GPT partitions, and so on).

Of course this has to be tested, but I believe it can be done. :unsure: (though still, besides the "because I can do it" reason it has to be found out if it has an actual practical use :dubbio:)

 

The differences with the "grldr floppy partition" approach - provided that it actually works to fully boot the OS - something that seemingly noone tested or reported (I still find it "cleaner", not because I put it together :smiling9:, really, but because it is "cleaner" ;)) are two, in your solution:

  1. you use the grub2 to load the grub.exe (and this - though it can be a nice option :) for people using anyway GRUB2 is a tadbit too complex for my personal tastes, and I believe - though I haven't tested it - that the GRUB2 install will need a few sectors outside the MBR written to disk that may be an issue) 
  2. you *need* to have the "(hd1,3)" listed as a partition in the GPT partitioning

The "grldr floppy partition" way:

  1. only "touches" the MBR code (which is ignored)
  2. the small partition can be either (it is a choice) be listed in the GPT partitioning or it can be "hidden" or "perfectly transparent" to it

BTW, at first sight there should be no issues to "combine" the two, i.e. still use the "modified" MBR makebootfat code to load the "(hd1,3,0)" and have the (hd1,3) be a "direct" grub4dos grldr.mbr install.

I see as an advantage to not have GRUB2 needed and load directly or "as directly as possible" the grub4dos, as IMHO there are far less risks of issues.

 

As a side note, I checked the makebootfat source code and it's MBR code (the one I "half-@§§dly hacked" :w00t: :ph34r:) is actually derived by the Syslinux one, so, once again, we have to thank H.Peter Anvin and the Syslinux project :worship:.

 

:duff:

Wonko 



#24 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 08 September 2014 - 11:44 AM

The bad news are that you can have ONLY one partition in the (hd1,3) MBR (i.e. the "(hd1,3,0)", the good news are that most probably you can use the second partition entry in the (hd1,3) MBR to point to another (fake) EMBR (into which you can map another of the GPT partitions, and so on).
Of course this has to be tested, but I believe it can be done. :unsure: (though still, besides the "because I can do it" reason it has to be found out if it has an actual practical use :dubbio:)

 
Oh no, no more chained "logical" (the arrangement is highly illogical according to me) partitions. At least not unless its inevitable.
 

I see as an advantage to not have GRUB2 needed and load directly or "as directly as possible" the grub4dos, as IMHO there are far less risks of issues.


I agree. I'm only using Grub2 now because of ease of testing - each new possibility becomes an entry.
 

As a side note, I checked the makebootfat source code and it's MBR code (the one I "half-@§§dly hacked" :w00t: :ph34r:) is actually derived by the Syslinux one, so, once again, we have to thank H.Peter Anvin and the Syslinux project :worship:.


That is exactly what I'm planning to do when I polish the current work into something more people can use... gptmbr from syslinux is the most compact way of loading from a GPT disk from BIOS currently. Remind me again though, why did you seek makebootfat, rather than use \syslinux\gptmbr.bin, which has always been a more standard boot code?
 

I still find it "cleaner", not because I put it together :smiling9:, really, but because it is "cleaner" ;)

 
How so? It's hard to change bootmgr and/or bcd that way... Of course, unless WinVBlock is used as here, the same applies to embedded MBR approach.
 

I believe - though I haven't tested it - that the GRUB2 install will need a few sectors outside the MBR written to disk that may be an issue

 
Nope, Grub2 uses ef02 partition, remember?
 

[...] you *need* to have the "(hd1,3)" listed as a partition in the GPT partitioning
[...] the small partition can be either (it is a choice) be listed in the GPT partitioning or it can be "hidden" or "perfectly transparent" to it

 

But surely, having it listed as a partition, or present as files/data somewhere visible is the point...? What's the advantage in hiding the boot manager, other than making it difficult to edit?

 

BTW, at first sight there should be no issues to "combine" the two, i.e. still use the "modified" MBR makebootfat code to load the "(hd1,3,0)" and have the (hd1,3) be a "direct" grub4dos grldr.mbr install.


Why all that? Giving up the WinVBlock component means that we can modify \syslinux\gptmbr.bin to boot the first sector of ef01, just like grub2 mbr boots the first sector of ef02. All the complication disappears this way.

 

I see here a tradeoff between "transparency" and "simplicity" : It's too easy to shove bootmgr and bcd in some sectors somewhere and still boot, but for it to be available to edit later, requires more work, such as what this thread is about. 



#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 September 2014 - 03:09 PM

The \gptmbr in syslinux does not allow me (without much editing of course) to have also the "whole disk" set as root in grub4dos, which the current makebootfat MBR instead allows (i.e. it needs not to edit the grldr embedded menu.lst).

 

Really, the idea when someone posts something is that it is READ, possibly a few times, before asking about it, particularly when the answer to the specific question is already written:

http://reboot.pro/to...o-gpt/?p=186471

 

When (if) you will have a GPT disk created under a Windows system, filled up to the brim, with no EF02 partition, without the possibility to re-size an existing partition and re-partition to create a EF02 partition, and you will want to boot it from a BIOS machine, then you might see how the approach may be of use.

 

The BOOTMGR \boot\BCD do not really (again as already said in the other thread):

http://reboot.pro/to...o-gpt/?p=186768

need to be "inside" the small grldr volume, the point is only about loading grub4dos, and from it there are no issues that I can see.

 

:duff:

Wonko







Also tagged with one or more of these keywords: gptmbr, map, driver

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users