How to embed MBR partition table within a GPT partition?

My current issue is that the BIOS in my Sager is capable of booting in either legacy or UEFI mode, but both options can't be enabled at the same time, even if CSM is enabled and Secure Boot is off. So if set to UEFI off in BIOS, I can only see legacy boot options. And if UEFI is enabled, legacy boot options don't appear. I've been keeping track of the Prema BIOS mod that will hopefully be released in the next few months for my model, in which case this limitation should be nixed. But at present I would like to boot both UEFI and legacy-capable OSes on the same disk, while still keeping UEFI as my preferred boot method and GPT as the preferred partition table style for all internal drives.

So that leaves me with a few options that I've been milling over for a few years (long before I bought this laptop):

1. BIOS on GPT, this may be an issue since I would like to encrypt my C drive with BestCrypt Volume, booting it in legacy mode, with most other OSes booting in UEFI mode.

2. Hybrid MBR, may work but limits me to 4 legacy OSes on the MBR, and gdisk doesn't support creating logicals within an extended, and Windows booted in legacy will only see the MBR side while ignoring the GPT partitions. It looks a bit difficult to set up and maintain, and Rod Smith makes every effort to discourage its' use.

3. VHD within a GPT NTFS partition, with the VHD itself having an MBR partition table. I'm pretty my encryption solution doesn't supporting crypting a VHD, and I'm also sure the boot files will need to be elsewhere, and chainloadable by an external bootloader.

4. UEFI DUET or Clover for booting all OSes in UEFI except Windows. The standalone DUET I have does work on my hardware but isn't completely reliable, with the exception of the one embedded into Clover, which works fine. But Clover negates the need to use it.

5. Windows' boot files stored in a partition on a MBR disk (used for data only and located on an internal HDD), while the C drive itself sits in a partition on my main GPT disk (SSD).

6. And now, to get to the title of the topic, I had been reading Rod Smith's hybrid MBR page, at the end he spoke of another kind of hybrid MBR that involves embedding an MBR disk within within a GPT partition. I know that GPT has a code that specifies a partition allocated for this use. I also know that I can use various partitioning utilities to set these flags and codes. But how would I go about installing legacy Windows within that (once set up)? Would Windows be able to see the entire GPT disk too (since it must anyway transition from real to protected mode, then enumerate disks/partitions/volumes with its' inbuilt drivers? I also assume I'll need a GPT/MBR-aware bootloader to chainload this setup. I think this is the best approach overall since it negates most of the other methods' downsides.

If there's anything I missed or other alternative methods that may be better suited, clue me in.

Thanks!

1. BIOS on GPT, this may be an issue since I would like to encrypt my C drive with BestCrypt Volume, booting it in legacy mode, with most other OSes booting in UEFI mode.

May or will?

 

Seemingly the Bestcrypt loader can be moved from the MBR:

http://www.jetico.co..._in_version.htm

 

 

8. BestCrypt Volume Encryption (BCVE) does not modify reserved sectors on the hard drive to store its boot code when the user encrypts system/boot volume. As a result, BCVE does not conflict with other software that may wish to use the sectors (like Windows dynamic disk support, Adobe protection scheme, system boot recovery programs). But BCVE still needs to modify MBR sector.

Since v.2 advanced users can move contents of BCVE code from MBR to first sector on removable device (floppy or USB stick) and restore original contents of the MBR sector. After that boot of encrypted operating system is possible only from the removable device, or, if the computer is dual-boot, only not encrypted system will load without displaying BCVE boot-time password prompt.

Several interesting schemes of booting computers can be invented with the help of the feature, example for dual-boot computers is only one of them. Although now the functionality is helpful rather to advanced users, future versions of BCVE will use it for enhancing security of the software.

It seems like the UMBR:

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

grub4dos and a virtual floppy in it may make it work, but of course this will depend on which Windows you plan to boot this way.

 

Wonko

BIOS on GPT itself shouldn't present an issue, but when you throw disk encryption into the mix.....well.....which is why I said it *MAY* present an issue nonetheless. And the BIOS on GPT has the issue of (last time I read) Windows not being able to find its' boot files after the OS is loaded. This could cause certain updates to fail too.

 

I figured the BC loader loader could be moved from the MBR by just making a copy of the first sector. However, BC can boot in either UEFI or legacy mode, depending on how Windows is installed. If it detects a legacy install, it copies the BC loader sata into the MBR. But if it detects UEFI, it will ignore the MBR and install the BC loader files into the EFI system partition. The BC loader in the MBR will expect an MBR partition table, so when confronted with a GPT partition table, it might lose its' marbles. Likewise, the BC UEFI loader will expect GPT.

 

What, exactly, is a UMBR? If what you linked is correct, the parallel that comes to mind most quickly is:

 

Syslinux installed in protective MBR, which chainloads the UEFI DUET (PBR/VBR?) in the EFI system partition, which then allows you to load a UEFI-capable OS. Clover works essentially the same on the legacy end.

 

I still would like to know more about the MBR within GPT partition approach. It just seems like it might be promising.

 

I would like to do some experiments almost immediately (in a VM) but need some ideas to test.

 

Edit: The Windows OS I'm booting is 10, which is the Windows version my CPU officially supports (i7-7700K).

It is simply a special MBR code (to be put in a BIOS PC but on a GPT style disk first sector) that simply chainloads (no matter what is in the GPT tables) a grldr  (that can be *anywhere* on disk).

The same effect of my previous attempt, when I made the MBR code load a "fake" partition holding the grldr.

The original idea was to have a "same" disk (GPT) capable of booting *something* both when normally connected to a UEFI system and when connected to a BIOS system, but - unlike a hybrid MBR -  setup in such a way that nothing "overlaps".

 

Surely it has to be seen how it behaves with Bestcrypt, but at least in theory, it should work.

 

Wonko

 

 

It is simply a special MBR code

 

What do you mean by "it"? The UMBR? Or you meant that MBR within a GPT partition uses a special code (which it does)? How does "it" chainload? By sector or a range of sectors (in which case it doesn't matter what the partition table says, since you're giving it an exact location)? It's my understanding that all disks have a fixed number of sectors, so it's easy to reference them. grldr can be embedded into sectors even if a partition/volume isn't present? I also Googled for UMBR, what I found is a file that is much larger than 512 bytes (the MBR's size). So if it is to be in the MBR, then it will most likely have to overwrite something critical, like the partition table. There seems to be very little info about it.

 

I suppose it would be useful (maybe) to provide the BC loader with a fake MBR partition table. But I don't want to have to do this unless it's necessary. I still suspect it will freak out when it expects MBR and sees GPT. Or that it will check the disk and not allow encryption at all. For now, I have only the goal of booting encrypted Windows in legacy mode, with most other OSes in UEFI mode. Maybe I will try a dual legacy/UEFI Windows later that can be booted in either mode.

 

More clarification is needed on exactly which approach you're suggesting. BIOS on GPT? Or MBR embedded within a partition table, which would be the "other" hybrid MBR referenced by Rod Smith at http://www.rodsbooks...isk/hybrid.html (bottom of page). He even links to a detailed PDF file. In essence this "other" hybrid MBR is also BIOS on GPT, but I dont think it uses the same approaches as some of the stuff described in the thread by milindsmart (virtual floppies, wimboot, VHDs, etc). I would like to keep the *same disk* usable for both legacy and UEFI OSes, while maintaining a mostly standard GPT layout (I'm pretty sure that boot code embedded into the protective MBR violates the UEFI specs, but I don't care as long as it serves my needs).

 

I would also like to avoid using GRUB4DOS if possible. For one, it will make the boot process even longer and probably require manual input. It seems to be able to read GPT but cant handle UEFI, so I wouldn't consider it as my main bootloader. My preference is GRUB2. I was planning on embedding Clover into the MBR then using that for legacy and emulated UEFI booting, and chainloading other loaders like G4D. I have been able to find numerous how-to's on installing G4D on a MBR disk, but no clear instructions for installing it to a GPT disk.

 

Right now I'm still looking into doing tests in a VM first, but without an idea of how to proceed or what to do, that is at a standstill. It's like telling a lifelong blind person that the sky is blue. They have never seen it for themselves so how can they be 100% sure? They have to take the word of others. I did read into the BIOS on GPT topic again, and I think the best approach for that is a MBR VHD for boot files only, while Windows lives in a regular (non-VHD) GPT partition. Will this work? A TechNet article seems to say that it would (https://technet.micr...s/dn858566.aspx), but it also seems to say that the C drive must be in a VHD too. And even if this does work, I'm sure an external loader will be required to find and mount the VHD before Windows can even begin to boot. I think a VHD with MBR boot files should meet my requirement of Windows (and, come to think of it, BestCrypt) being able to find its' boot files, or at least the possibility of being able to manually mount it (System Reserved volume) when doing updates and working with it generally. If an update needs to access/update something there (entirely possible) and can't find it, there will be issues. This may not be a valid concern to you but it is to me, I'm being logical about it. Which is one of the reasons why I didn't bother with the BIOS on GPT approach at all. And last, I will use G4D for testing, although I don't prefer it. How would go about installing it and chainloading it so the boot Windows on GPT from MBR VHD idea can be tested?

 

And since the title of the topic still is "How to embed MBR partition table within a GPT partition?", where can I get info on that? I mean procedures generally. Even if it doesn't turn out to be useful, testing it might still be a fun learning experience nonetheless. I found a thread here (lost the URL) where it was being discussed, can't find it now though.

The UMBR is a special code for the MBR BUT intended to be written to the (otherwise unused) code area of the protective MBR of a GPT disk.

You don't have to google for it, I provided a link:

http://reboot.pro/to...-11#entry197690

to where the thingy is (on Chenall's pages):

http://chenall.net/post/grub4dos_umbr/

which with a little effort can be understood alright with Google translate.

And sure, I quoted your item #1, so it is Bios on GPT.

 

If you - instead (why?) you want to try - still within the BIOS on GPT, the "fake partition" method, links are given in the post immediately after the referenced one:

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

 

Both need to use grub4dos, and not GRUB2, at least initially, so you need BIOS (and not UEFI) which anyway it is the whole point of the BIOS on GPT.

 

If you want to end up with UEFI you need anyway to go through Clover (or similar) that adds UEFI capabilities to BIOS, but there are no issues (if Clover works in your setup) to chainload clover from grub4dos:

http://reboot.pro/to...-from-grub4dos/

 

so boot sequences may be:

1) BIOS->UMBR->grub4dos->menu.lst->*whatever* BIOS based

2) BIOS->UMBR->grub4dos->menu.lst->Clover->*whatever* UEFI based

 

Of course in grub4dos you will need to choose what you want to boot (the *whatever* BIOS based, one or more choices) or Clover (and then in Clover if you have more than one UEFI based OS you will need to choose another time), but if you are fast in your choice it's not like the booting will be that much longer.

 

The "other" hybrid MBR simply does not exist:

 

The idea is that GPT-unaware OSes could, with the help of a modified boot loader, boot from the GPT partition as if it were a hard disk. As written, this document only mentions in passing the MBR Partition Scheme (GPT fdisk code EF01) that's already defined; instead, it emphasizes setting a new attribute bit.

 

To the best of my knowledge, no boot loader or OS currently implements this alternative type of "hybrid MBR" configuration. If you hear of such an implementation, I'd be interested in learning about it.

the issue here is that not only the boot loader would need to be modified (and the mentioned BIOS on GPT solution with the "fake" partition loader would do for this) but the OS needs to be aware of the GPT scheme and of the EF01 partition (and none does that).

 

If you read towards the end of the BIOS on GPT thread, starting from here:

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

you will see how Steve6375 used the UMBR and Clover to boot a Windows 10 on GPT starting from BIOS:
http://www.rmprepusb...s/bios_gpt_boot

 

 

Wonko

Stuck again.....

 

1. Created 10 VDI in VirtualBox, configured VB to boot in BIOS mode

2. Created 2 NTFS partitions on said disk (in GParted), the first has the flags of "boot, legacy boot, esp"

3. Used ImageX to install the contents of a WIM file into the 2nd partition

4. Created a 128MB VHD within partition #1, force-installed the MBR to that VHD with bootsect, then installed boot files to volume within the VHD, and marked that volume as active

 

But still, *HOW* to install the UMBR to the protective MBR of the VDI? The links you gave have unclear instructions.

I don't understand what you are trying to do (actually how you are trying to do that).

 

The VHD is an added complication and it is not clear at all what is the scope of it, of course you can use a VHD (possibly a fixed size vhd, ie. a disk RAW image or a floppy/superfloppy image) but that would be useful only for BIOS booting (of a BIOS on GPT).

 

The idea (general) for the final goal (of the BIOS on GPT but booting the windows in UEFI mode) is to have a BIOS, initiate the boot from BIOS, load through the UMBR a grub4dos grldr, then pass to Clover (please read as UEFI) and continue booting in UEFI mode (that should imply - unless you use the Rufus NTFS UEFI driver - a FAT partition for the Windows boot files).

The whole point being that the same, unmodified setup should be able to boot directly in UEFI mode.

 

So, you should work backwards, you should first thing make a "normal" Windows install in UEFI mode on GPT, and then later add to the mix the UMBR, grub4dos and Clover and switch to BIOS booting.

 

Or you could follow EXACTLY the mentioned blogpost by Steve6375:

http://www.rmprepusb...s/bios_gpt_boot

it provides also a set of batches (cmd and grub4dos) that should make the UMBR setup easy, but it is not that difficult, you boot to grub4dos and then run (contents of the

gptmbr.g4b grub4dos batch):

(hd0,0)/GPT/umbr -d=1 (hd1,1)/grldr

 

Which means:

<path to umbr file>/umbr <- in that case (hd0,0) the path is to first partition on first disk (the USB Easy2boot stick)

-d=1 <- this is disk 1, i.e. second disk, the GPT "internal" disk

<path to grldr file>/grldr <- in that case it is (hd1,1) i.e. second partition on second disk, i.e. the "boot" (or "system" as MS calls it) FAT partition on the GPT "internal" disk, where you need to copy grldr (before)

 

What the command does is simply to write the UMBR code to the target disk protective MBR, calculating on the fly the blocklist/extents of the "target" grldr copy.

 

This won't work if the grldr is inside a VHD (or however image) but you could anyway calculate the blocklist of the grldr copy within the image and use the direct blocklist/extents syntax, using the absolute data of the grldr on the disk, *like*:

(hd0,0)/GPT/umbr -d=1 (hd1)offset+length

 

Wonko

I have no idea exactly what you're trying to say, or exactly what you're suggesting to do. Everything you're posting is just adding to the confusion. The overall goal is to be able to boot 10 in either legacy or UEFI mode, while still being encrypted either way, and Windows Updates/Repair/etc still working. If I had wanted to do a pure UEFI setup on GPT then I can, my hardware is 100% compatible with UEFI. No need to use Clover for emulated UEFI booting. If the whole point is to loop back around to UEFI, either emulated or pure/real, then why bother with legacy at all?

 

The whole point of using a VHD for boot files is that I can boot in legacy mode, while still giving the OS a fake MBR (on that small VHD) so that it thinks it is booting in legacy mode. BestCrypt can also read that VHD's MBR and (hopefully) install its' boot code there (to be chainloaded by G4D or whatever). And then, UEFI is also possible, BC and Windows can install the UEFI versions of their boot files on the EFI System Partition.

 

The original intent was to be able to have legacy and UEFI OSes being able to boot on the same GPT disk, by embedding MBR within a GPT partition. But you say that isn't possible, which leaves Rod Smith's hybrid MBR approach as the only thing left. But that still limits me to a max of 4 legacy OSes. So then, I had began to think that using virtual disks (VHD, IMG, etc) might be an alternative, you can just give the virtual disk an MBR partition table for the legacy OSes to read.

The original intent was to be able to have legacy and UEFI OSes being able to boot on the same GPT disk, by embedding MBR within a GPT partition. But you say that isn't possible, which leaves Rod Smith's hybrid MBR approach as the only thing left. But that still limits me to a max of 4 legacy OSes. So then, I had began to think that using virtual disks (VHD, IMG, etc) might be an alternative, you can just give the virtual disk an MBR partition table for the legacy OSes to read.

 

Good, but the WHOLE point of the "BIOS on GPT" (item #1 in your list) is to be able to use the SAME disk, UNmodified, to boot BOTH as BIOS or as UEFI, I am talking of that item and of that item only.

 

Of course you normally need to switch firmware mode (by accessing it at boot time) before to either BIOS or GPT.

 

Adding Clover (or another UEFI emulator) may allow (on suitable hardware) to leave the firmware always in BIOS mode, go through the UMBR and grub4dos and from its menu.lst decide if continuing booting in BIOS mode this (or that) OS or load Clover and continue to boot (in UEFI mode) this (or that) OS.

 

In the case of Windows 10 you could boot the SAME OS install in either BIOS or UEFI mode without changing settings in the firmware.

 

Specifically for Windows 10 using the BIOS booting does not allow hybernation and updates, so from time to time you would need to boot the Windows 10 in UEFI mode (via Clover or changing the firmware) to have updates working.

 

Let's see if this explains the matter, when booting you will have two options (with firmware set to BIOS, or CSM):

BIOS->UMBR->grub4dos-> Choice #1->Windows 10 booted in BIOS mode

BIOS->UMBR->grub4dos-> Choice #2->Clover->Windows 10 booted in UEFI mode

 

For the record, there is NO such limit as 4 "legacy" OS's on MBR, however.

The limit of MBR is of four primary partitions, and as a matter of fact all NT based systems (at least up to 7, 10 may well have changed ) and all Linux Systems were designed to be bootable (and perfectly working) from a logical volume inside extended (only the actual loaders needed to be on a primary partition, and this requirement has been later invalidated by the coming of grub4dos and similar boot managers). 

 

In the good ol' times you made a single primary partition (bootable/active) and one single extended partition where you could have as many volumes as you wished to have, I had multiboot systems with:

1) DOS <- must be in a primary partition on first disk

2) Windows NT 4.0 <- originally designed explicitly to be run from a logical volume in extended partition

3) Windows 98 <- yes also Windows 98 can be installed with a few tricks in a logical volume

4) Linux <- originally designed explicitly to be run from a logical volume in extended partition

5) Windows 2000 <- like NT 4.0

6) Windows XP <- like NT 4.0 and 2000

7) BeOS (on a second primary partition)

... and still had one free slot in the MBR.

 

Wonko

Good, but the WHOLE point of the "BIOS on GPT" (item #1 in your list) is to be able to use the SAME disk, UNmodified, to boot BOTH as BIOS or as UEFI, I am talking of that item and of that item only.

 

Of course you normally need to switch firmware mode (by accessing it at boot time) before to either BIOS or GPT.

 

Adding Clover (or another UEFI emulator) may allow (on suitable hardware) to leave the firmware always in BIOS mode, go through the UMBR and grub4dos and from its menu.lst decide if continuing booting in BIOS mode this (or that) OS or load Clover and continue to boot (in UEFI mode) this (or that) OS.

 

In the case of Windows 10 you could boot the SAME OS install in either BIOS or UEFI mode without changing settings in the firmware.

 

Specifically for Windows 10 using the BIOS booting does not allow hybernation and updates, so from time to time you would need to boot the Windows 10 in UEFI mode (via Clover or changing the firmware) to have updates working.

 

Let's see if this explains the matter, when booting you will have two options (with firmware set to BIOS, or CSM):

BIOS->UMBR->grub4dos-> Choice #1->Windows 10 booted in BIOS mode

BIOS->UMBR->grub4dos-> Choice #2->Clover->Windows 10 booted in UEFI mode

 

For the record, there is NO such limit as 4 "legacy" OS's on MBR, however.

The limit of MBR is of four primary partitions, and as a matter of fact all NT based systems (at least up to 7, 10 may well have changed ) and all Linux Systems were designed to be bootable (and perfectly working) from a logical volume inside extended (only the actual loaders needed to be on a primary partition, and this requirement has been later invalidated by the coming of grub4dos and similar boot managers). 

 

In the good ol' times you made a single primary partition (bootable/active) and one single extended partition where you could have as many volumes as you wished to have, I had multiboot systems with:

1) DOS <- must be in a primary partition on first disk

2) Windows NT 4.0 <- originally designed explicitly to be run from a logical volume in extended partition

3) Windows 98 <- yes also Windows 98 can be installed with a few tricks in a logical volume

4) Linux <- originally designed explicitly to be run from a logical volume in extended partition

5) Windows 2000 <- like NT 4.0

6) Windows XP <- like NT 4.0 and 2000

7) BeOS (on a second primary partition)

... and still had one free slot in the MBR.

 

Wonko

 

This is such an informative post! Clarifies for all OSes & booting