MBR partition parsing

[BenLunt]

Hi guys,

With the discussion over in http://forum.osdev.org/viewtopic.php?f=2&t=32409, I thought it would be wise to test my MBR code.

I allow a depth of up to 127 nested extended partitions, searching each limb until I find a partition entry marked active.

However, something I have always wondered is the fact of what partitioning scheme, using this MBR and extended partition entries, can be used, should be used, or should not be used. For example, a well known name-brand software manufacture allows only one extended entry *and* one regular entry per table, then embeds extended partitions within parent extended partitions. Is this the norm or the requirement? I think the former more than the latter.

Anyway, I placed a few notes and some test code along with a small test image at http://www.fysnet.net/blog/2017/09/.

I would appreciate any comments, posted here of course, about your idea of how a MBR partitioning scheme should/must/can/may be designed.

Also, the code is to test your MBR code. Does your code allow nested partitions?

Thanks,
Ben

[Brendan]

Hi,

I would appreciate any comments, posted here of course, about your idea of how a MBR partitioning scheme should/must/can/may be designed.

In theory; it's all "de-facto non-official conventions" and you can do whatever you like. In practice I doubt any OS supports nesting properly - e.g. you can split a primary partition into (up to 4) extended partitions and expect most OSs to understand that; and you can split an extended partition into (up to 4) "extended extended partitions" but most OSs won't understand that.

Note that "you can do whatever you like" includes "BSD slices" (which allow a primary partition to be split into up to 16 sub-partitions) and "hybrid GPT"; and doesn't exclude anything else (what your OS does with its partition is your OSs concern, and if your OS wants to split its partition into sub-partitions using a method that no other OS supports then that's perfectly fine).

For my OS; I'm thinking of only supporting "hybrid GPT", where the OS itself only uses GPT (and ignores MBR) and the MBR (ideally) contains 2 primary partitions - one small partition (for BIOS compatibility) that contains enough code to understand GPT and load/boot a file from an EFI system partition, and one huge protective partition to tell legacy OSs that the entire rest of the disk is in use (by GPT). One of the benefit of this scheme is that the same disk can support both BIOS and UEFI at the same time, so that if the user changes their firmware settings (between BIOS and UEFI) or shifts the storage device to a different computer my OS would still boot without any problem.

Also, the code is to test your MBR code. Does your code allow nested partitions?

Why would MBR code care?

The MBR code finds an active partition, loads the 1st sector of that partition and passes control to it. If that primary partition happened to be subdivided into extended partitions then the 1st sector of the primary partition would have code to find an active extended partition, load the 1st sector of it and pass control to it. With full nesting, the extended partition could have another partition table (to describe "extended extended partitions") and more code to chain-load the 1st sector of the active "extended extended partition", and so on, to any depth you like.

The MBR's code wouldn't be any different at all.


Cheers,

Brendan

[BenLunt]

Hi,

For my OS; I'm thinking of only supporting "hybrid GPT", where the OS itself only uses GPT (and ignores MBR) and the MBR (ideally) contains 2 primary partitions - one small partition (for BIOS compatibility) that contains enough code to understand GPT and load/boot a file from an EFI system partition, and one huge protective partition to tell legacy OSs that the entire rest of the disk is in use (by GPT). One of the benefit of this scheme is that the same disk can support both BIOS and UEFI at the same time, so that if the user changes their firmware settings (between BIOS and UEFI) or shifts the storage device to a different computer my OS would still boot without any problem.

This is a good idea and I do something very similar.

Also, the code is to test your MBR code. Does your code allow nested partitions?

Why would MBR code care?

The MBR code finds an active partition, loads the 1st sector of that partition and passes control to it. If that primary partition happened to be subdivided into extended partitions then the 1st sector of the primary partition would have code to find an active extended partition, load the 1st sector of it and pass control to it. With full nesting, the extended partition could have another partition table (to describe "extended extended partitions") and more code to chain-load the 1st sector of the active "extended extended partition", and so on, to any depth you like.

The MBR's code wouldn't be any different at all.

I see it differently. I have never seen a partition entry type of 5 or 15, an extended partition entry, marked active. Also, what if one of the partition entries within these extended partitions is the active entry. How does the MBR get to it?

Either I misunderstood your words above or you misunderstood mine from before.

Let's say that the partition table in the first sector of the disk, the MBR, has four entries, the first being an entry of type 15, and extended entry, the remaining three entries are zeros. Please note that this first entry is not marked active. Is it the job of the MBR to then load the sector pointed to by this extended partition entry, then to parse its four partition entries? I think so.

I do not think, nor have I ever seen an extended partition's first sector have any code in it to parse its own partition entries. Never.

Here is what I think. Let's say we have the same scenario as above. A single used partition entry in the MBR sector, its type is 15, and extended partition entry. This entry points to LBA X. Then at LBA X, there are four more partition entries, two used, two unused. The first used is another extended partition type of 15 pointing to LBA Y. The second used is a normal partition type, say 7 for a NTFS partition. The sector at LBA Y has four partition entries with only one used, and this single partition entry is marked active.

Is it the job of the MBR code to find this partition entry within LBA Y, load the sector that this single partition entry points to? I think so. What are your thoughts?

As for nested partitions, the above scenario is considered a nested extended partition scheme. My code creates a dummy image so that--let's say that the second used partition in LBA X above, the NTFS partition, is now the partition marked active instead of the other at LBA Y--the image created tests your MBR code to see if it will get to LBA Y, notice that nothing is marked active and come back to LBA X and find the second partition active.

This is how I see the Legacy BIOS MBR partitioning scheme. Yes?

Ben

P.S. To get back to my original post, this is from https://en.wikipedia.org/wiki/Extended_boot_record.

EBRs have essentially the same structure as the MBR; except only the first two entries of the partition table are supposed to be used,

"supposed to be used". Who said this and why should only the first two be used? Not trying to discredit anyone, I just would like to know the reasoning for this and why someone chose to do it this way.

[Brendan]

Hi,

Also, the code is to test your MBR code. Does your code allow nested partitions?

Why would MBR code care?

The MBR code finds an active partition, loads the 1st sector of that partition and passes control to it. If that primary partition happened to be subdivided into extended partitions then the 1st sector of the primary partition would have code to find an active extended partition, load the 1st sector of it and pass control to it. With full nesting, the extended partition could have another partition table (to describe "extended extended partitions") and more code to chain-load the 1st sector of the active "extended extended partition", and so on, to any depth you like.

The MBR's code wouldn't be any different at all.

I see it differently. I have never seen a partition entry type of 5 or 15, an extended partition entry, marked active. Also, what if one of the partition entries within these extended partitions is the active entry. How does the MBR get to it?

Either I misunderstood your words above or you misunderstood mine from before.

Let's say that the partition table in the first sector of the disk, the MBR, has four entries, the first being an entry of type 15, and extended entry, the remaining three entries are zeros. Please note that this first entry is not marked active. Is it the job of the MBR to then load the sector pointed to by this extended partition entry, then to parse its four partition entries? I think so.

No; in that case the MBR's code checks for a primary partition that is marked active, finds that is no active primary partition, and displays a "nothing is bootable" error.

Lets say that the MBR's partition table has 4 entries, where the first one is marked active and the MBR's code has no reason to care what type it is. The MBR's code loads the 1st sector of the 1st partition and passes control to it (the same as it always has). Now let's say that the 1st primary partition was type 15, and its 1st sector contains another partition table (describing the extended partitions). Code in the 1st sector of the 1st primary partition (which was started by the MBR) finds an extended partition that's marked as active, loads the 1st sector from the extended partition, and passes control to it.

You can think of it like:

Code: Select all

    MBR (loaded by BIOS)
     |_primary_partition_1 (active)
     |  |_1st sector of partition 1 (loaded by MBR)
     |     |_extended_partition_1:1
     |     |_extended_partition_1:2
     |     |_extended_partition_1:3 (active)
     |     |  |_OS boot loader (loaded by 1st sector of partition 1)
     |     |_extended_partition_1:4
     |_primary_partition_2
     |_primary_partition_3
     |_primary_partition_4

With more nesting, you could have:

Code: Select all

    MBR (loaded by BIOS)
     |_primary_partition_1 (active)
     |  |_1st sector of partition 1 (loaded by MBR)
     |     |_extended_partition_1:1
     |     |_extended_partition_1:2
     |     |_extended_partition_1:3 (active)
     |     |  |_1st sector of partition 1:3 (loaded by 1st sector of partition 1)
     |     |     |_extended_partition_1:3:1
     |     |     |_extended_partition_1:3:2
     |     |     |_extended_partition_1:3:3
     |     |     |_extended_partition_1:3:4 (active)
     |     |        |_1st sector of partition 1:3:4 (loaded by 1st sector of partition 1:3)
     |     |           |_extended_partition_1:3:4:1
     |     |           |_extended_partition_1:3:4:2 (active)
     |     |           |  |_OS boot loader (loaded by 1st sector of partition 1:3:4)
     |     |           |_extended_partition_1:3:4:3
     |     |           |_extended_partition_1:3:4:4
     |     |_extended_partition_1:4
     |_primary_partition_2
     |_primary_partition_3
     |_primary_partition_4

The reasons for this are:

• It's too hard to deal with all this in the (< 512 bytes of) MBR code
• It's trivial to extend to any amount of nesting
• It allows an OS to use its own very different "sub partitioning" scheme with its own "1st sector of primary partition" that understands that "sub partitioning" scheme
• For all of these things; it works with every existing MBR without any compatibility problems

I do not think, nor have I ever seen an extended partition's first sector have any code in it to parse its own partition entries. Never.

The reason you haven't seen it is that most OSs don't support booting from an extended partition in the first place (and only support booting from a primary partition).

Here is what I think. Let's say we have the same scenario as above. A single used partition entry in the MBR sector, its type is 15, and extended partition entry. This entry points to LBA X. Then at LBA X, there are four more partition entries, two used, two unused. The first used is another extended partition type of 15 pointing to LBA Y. The second used is a normal partition type, say 7 for a NTFS partition. The sector at LBA Y has four partition entries with only one used, and this single partition entry is marked active.

Is it the job of the MBR code to find this partition entry within LBA Y, load the sector that this single partition entry points to? I think so. What are your thoughts?

As for nested partitions, the above scenario is considered a nested extended partition scheme. My code creates a dummy image so that--let's say that the second used partition in LBA X above, the NTFS partition, is now the partition marked active instead of the other at LBA Y--the image created tests your MBR code to see if it will get to LBA Y, notice that nothing is marked active and come back to LBA X and find the second partition active.

This is how I see the Legacy BIOS MBR partitioning scheme. Yes?

This is how you see it; but it's not how I see it. I'd consider it poor engineering (inflexible, impractical and incompatible).

P.S. To get back to my original post, this is from https://en.wikipedia.org/wiki/Extended_boot_record.

EBRs have essentially the same structure as the MBR; except only the first two entries of the partition table are supposed to be used,

"supposed to be used". Who said this and why should only the first two be used? Not trying to discredit anyone, I just would like to know the reasoning for this and why someone chose to do it this way.

That Wikipedia page is very dodgy (e.g. the entire second paragraph is completely wrong and the cited references don't back up the incorrect statements made).


Cheers,

Brendan

[Antti]

Also, the code is to test your MBR code. Does your code allow nested partitions?

It depends on how we define them but my code does not disallow them in general. There is as little policy as possible.

[...]

Hopefully some consensus is reached. Meanwhile, the dummy MBR of mine can be used to chain-load itself. Please note that this has nothing to do with my MBR's validity to work as an MBR (and that is the intended purpose of it). This toy experiment is just for showing that it tolerates some misuse too.

Code: Select all

  GMBR #1                               (loaded by BIOS)
   |_Primary_Partition_1                (active)
      |_1st_Sector_of_Partition_1       (GMBR #2, loaded by GMBR #1)
         |_Extended_Partition_1_1       (active)
            |_OS_Boot_Loader            (loaded by 1st sector of partition 1, GMBR #2)

Quite nice, eh? Although it is too good to be true because there is one huge problem. The extended partition block must know absolute LBA values in its partition table and perhaps this is seen as a very inelegant detail. The group of (sub-)partitions is not an independent set of sequential blocks but there is one very annoying dependence on the absolute location on the disk. However, if the CHS values are still valid in the partition entries, this can be seen as the only reasonable option? The "base + offset" idea does not work very easily with CHS and would that even make common sense, generally speaking?

The MBR itself is the same: unaware of the "wiser" actions done by an institution that is well camouflaged and looks like a volume boot record.

[BenLunt]

This is how you see it; but it's not how I see it. I'd consider it poor engineering (inflexible, impractical and incompatible).

Don't get me wrong, I am not trying to say that you are wrong and I am right. It could be that you are right and I am wrong. My point to make is, where does it say that, where are the specifications, where are the requirements to back your idea? Where are they to back mine?

Who says that the MBR code (LBA 0) can only parse the four partition in its sector? Who says that an extended partition sector will have code in it to parse its own partition entries?

The reasons for this are:
- It's too hard to deal with all this in the (< 512 bytes of) MBR code
- It's trivial to extend to any amount of nesting

I have all of this code, to parse to a total depth of 127 deep (four entries each), checking for BIOS read extensions, checking for 386+, checking for and calling the TPM Hash, handling 64-bit LBA's, decent error messages, all in less than 512 bytes. I mean no disrespect, but this isn't a valid excuse. :-)

Besides, if a MBR is only to parse its own four entries, and an extended partition sector is only to parse its own four entries, nesting is not an issue.

I guess it is however the OS/Tool decides to partition the media, determines how it codes the MBR and extended partition sectors. A tool could create a MBR that only parsed its own four, and made sure the extended partition sector had its own code to parse its own four entries--or, it could create a MBR that parsed all entries, nested to 127 deep. :-)

I'm just curious if there was ever any official documentation stating how this is to be done. I don't think there ever was.

Thanks for your comments,
Ben

P.S. Oh, and one more thing, as Antti stated, if the extended partition sector is to parse its own entries, it must have a "I'm at this LBA" hard coded somewhere within its sector since all extended partitions are relative to its parent. With my MBR code, the only thing in all extended partition sectors are the four entries. Period. My MBR keeps track of where each one is. Just saying.

[Antti]

Oh, and one more thing, as Antti stated, if the extended partition sector is to parse its own entries, it must have a "I'm at this LBA" hard coded somewhere within its sector since all extended partitions are relative to its parent.

It does not have to be hard-coded. My example was a toy experiment and I used exactly the same MBR code. Real code designed for this would use the information that an MBR passes to it.

[Brendan]

Hi,

This is how you see it; but it's not how I see it. I'd consider it poor engineering (inflexible, impractical and incompatible).

Don't get me wrong, I am not trying to say that you are wrong and I am right. It could be that you are right and I am wrong. My point to make is, where does it say that, where are the specifications, where are the requirements to back your idea? Where are they to back mine?

Sadly, there are no official specifications. However, imagine back when extended partitions were first introduced - all existing MBR code couldn't have supported extended partitions and couldn't have booted from them (because extended partitions didn't exist when the MBR code was written); so at that time "MBR boots from extended partition" would've been impossible, and at that time "MBR starts EBR and EBR boots from extended partition" would've worked with all pre-existing MBRs.

Essentially, backward compatibility suggests that "MBR starts EBR and EBR boots from extended partition" is the most likely option (if an OS supports booting from an extended partition at all).

Of course most OSs don't support booting from an extended partition at all, and this could be considered "the most standard de-facto standard".

The reasons for this are:
- It's too hard to deal with all this in the (< 512 bytes of) MBR code
- It's trivial to extend to any amount of nesting

I have all of this code, to parse to a total depth of 127 deep (four entries each), checking for BIOS read extensions, checking for 386+, checking for and calling the TPM Hash, handling 64-bit LBA's, decent error messages, all in less than 512 bytes. I mean no disrespect, but this isn't a valid excuse.

If you could squeeze all of the code into 1 byte and use the remaining 511 bytes for ASCII error strings, the error messages will still be deficient. For a simple example, how much do you think it would cost to have a different error string for each error that BIOS disk services could return, so that you can display something like (e.g.) "ERROR: Failed to load EBR (BIOS returned 'no media in drive')" where the string corresponding to the BIOS's error code is inserted at the right place in another string)?

P.S. Oh, and one more thing, as Antti stated, if the extended partition sector is to parse its own entries, it must have a "I'm at this LBA" hard coded somewhere within its sector since all extended partitions are relative to its parent. With my MBR code, the only thing in all extended partition sectors are the four entries. Period. My MBR keeps track of where each one is. Just saying.

The MBR uses DS:SI or DS:BP to tell the EBR (or an OS's boot loader) the address of the partition table entry for the active primary partition, and EBR code can use this to find the starting LBA of the extended partition.


Cheers,

Brendan

[Brendan]

Hi,

For my OS; I'm thinking of only supporting "hybrid GPT", where the OS itself only uses GPT (and ignores MBR) and the MBR (ideally) contains 2 primary partitions - one small partition (for BIOS compatibility) that contains enough code to understand GPT and load/boot a file from an EFI system partition, and one huge protective partition to tell legacy OSs that the entire rest of the disk is in use (by GPT). One of the benefit of this scheme is that the same disk can support both BIOS and UEFI at the same time, so that if the user changes their firmware settings (between BIOS and UEFI) or shifts the storage device to a different computer my OS would still boot without any problem.

I'm thinking that if the user wants to boot a legacy OS (that doesn't support "hybrid GPT" and only supports MBR), the code in that "small partition (for BIOS compatibility)" could modify the MBR's partition table (dynamically construct a "third partition in MBR" from information from GPT) and then chainload the legacy OS's boot loader in the newly created MBR partition, and then fix/restore the MBR next time the computer is booted; so that as far as a legacy OS is concerned everything looks right (it has its own active partition in the MBR) and as far as all other OSs can tell the MBR isn't being used by any OS (the drive always looks like "hybrid GPT").

In this way you could also have many separate legacy OSs installed on the same computer, each with their own (dynamically constructed when needed) primary partition, plus many modern OSs that support "hybrid GPT" (and booting from BIOS or UEFI).


Cheers,

Brendan

[zaval]

A so called "hybrid GPT" is not standard and not supported by the UEFI specification and thus - compliant code; it might give more problems than benefits. More important, protective MBR should cover everything with GPT header and Partition Array inclusively up to the end of disk or up to the CHS limit. And GPT header and PA should be placed before any partitions. In fact, GPT header should be placed exactly at LBA=1. So it's hard to combine those with your "another small partition" - because your partition has no place to sit anywhere. Of course, it's possible to mark a partition with EE ostype field, but for compliant code this would mean the whole space after MBR is covered by this partition. if not, then behavior is "unpredictable".

[BenLunt]

I think what Brendan is talking about and what I do, is have one of the Protected MBR's partition entries point to one of the GPT partitions within the GPT space.

For example, an EFI boot will find the GPT, find the "active" GPT partition, and search for the boot.efi file, which in turn will boot the OS. On a Legacy BIOS boot, the BIOS will load the Protected MBR, find one of the partition entries active, load that VBR, which just so happens to be the first sector of the same partition the boot.efi file resides in. Then this VBR will, using Legacy BIOS services, boot the OS.

This is perfectly legal and allows the same partition (same volume) to be booted from either a Legacy BIOS boot or an EFI boot.

This is what I do for GPT partitioned media. Different boot loaders, but exactly the same kernel and drivers, just different forms of loading them.

Ben

[zaval]

I think what Brendan is talking about and what I do, is have one of the Protected MBR's partition entries point to one of the GPT partitions within the GPT space.

this is a problem already, since Protective MBR could have only 1 partition entry, it should be of 0xEE type, covering all the space behind MBR.

For example, an EFI boot will find the GPT, find the "active" GPT partition, and search for the boot.efi file, which in turn will boot the OS. On a Legacy BIOS boot, the BIOS will load the Protected MBR, find one of the partition entries active, load that VBR, which just so happens to be the first sector of the same partition the boot.efi file resides in. Then this VBR will, using Legacy BIOS services, boot the OS.

This is perfectly legal and allows the same partition (same volume) to be booted from either a Legacy BIOS boot or an EFI boot.

This is what I do for GPT partitioned media. Different boot loaders, but exactly the same kernel and drivers, just different forms of loading them.

Ben

As I've said it's not legal.
Generally, it's impossible to make GPT and Legacy MBR friends, every magic methods will turn to be a source of incompatibility and PITA in the future. You either have a disk with GPT and without usable MBR or just MBR. Protectiuve MBR by design could serve only one purpose - to protect GPT from legacy code not understanding GPT. Not even a hint on "booting" from it by this code. It should be marked as inactive, the quote:

Set to 0x00 to indicate a non-bootable partition. If set to
any value other than 0x00 the behavior of this flag on
non-UEFI systems is undefined. Must be ignored by
UEFI implementations.

Quite a clear answer on being "perferct legal", right?

UEFI could boot from non-GPT anyway, but trying to make legacy BIOS to boot from GPT is a bad idea. Better to just supply two layouts for installations - one for legacy and one for UEFI systems.

And UEFI doesn't have concept of "active" partitions. It searches for its payload by examining Boot options, held in its environment in non-volatile storage, and only then, if not succeeded, falls to the "default" behavior, well defined in section 3.4 "Boot Mechanisms" of the specification. Shortly, the UEFI Boot Manager after failing to load its payload from a normal options' defined scenario, will enumerate all removable "media" devices, followed by "fixed" ones. (although it's quite silly to expect a meaningful distinction between removable and persistent storage nowadays). Without specified order in the groups, it will try to load using FS protocol, then image protocol for every device, with possible additional enumeration if it happens that the device doesn't support FS protocol, but supports IO block protocol. then children of that device are tried too with the same algorithm. The FS protocol means booting from FAT (or any else FS, but it should be supported by the device handle, meaning the appropriate FS driver should exist), the "load image protocol" means loading some "obscure" PE image from a device that understands how to load the image "directly" from it, meaning the driver of this device is able to populate memory with the image by some specific to it means. and then passing to the loaded image all the remining FilePath so that the image could do farther job by itself.

Default loading for the FS variant adds to the path \efi\boot\boot{machine_type}.efi. It's only a fallback. And even "optional" for fixed media devices. Normally you use boot options having the path pointing to the image to load.
See, it's not like MBR booting, it requires from you to just put your loader into a proper location in the FS, basically you are free to put it wherever you want, just don't screw up Boot option creation so that it will point exactly where the file is.

It's not that hard having already different loaders for both scenarios just add two installation layouts for them. It looks easier for me, than that juggling trying to make BIOS work on GPT disks.

[Antti]

I've asked this question here and here but no answer.

However, this is exactly the way I wanted and tried to implement it too but I found those same ambiguities zaval is referring to when I read the specification. I would like to emphasize that the idea is good and perhaps I will implement it anyway if it becomes an accepted de-facto standard. Now the implementation is "on hold" until a good compromise is found.

[Brendan]

Hi,

A so called "hybrid GPT" is not standard and not supported by the UEFI specification and thus - compliant code; it might give more problems than benefits.

I doubt it matters in practice. For GPT, the only reason the protective MBR exists at all is to ensure that legacy OSs (that don't understand GPT) don't get confused when they see "unknown data". There is no reason for anything that is aware of GPT (other than tools to create/modify partitions) to look at the MBRs contents at all; and a legacy OS is going to expect multiple MBR partitions.

The only likely consequence is that a GPT disk partitioning tool might check the MBR's partition table and refuse to modify partitions. This is the opposite of a problem - it's exactly what you want if you're doing a hybrid scheme (and provide tools that update both MBR and GPT to suit the hybrid scheme).

Generally, it's impossible to make GPT and Legacy MBR friends, every magic methods will turn to be a source of incompatibility and PITA in the future. You either have a disk with GPT and without usable MBR or just MBR. Protectiuve MBR by design could serve only one purpose - to protect GPT from legacy code not understanding GPT. Not even a hint on "booting" from it by this code. It should be marked as inactive, the quote:

Set to 0x00 to indicate a non-bootable partition. If set to
any value other than 0x00 the behavior of this flag on
non-UEFI systems is undefined. Must be ignored by
UEFI implementations.

Quite a clear answer on being "perferct legal", right?

Yes. If the partition is marked as "active" in the MBR, then the behaviour of the flag is not defined by the UEFI specification (which doesn't and shouldn't define anything to do with legacy BIOS booting at all) but is still defined by pre-existing de-facto standards (where it should be defined), and this flag has to be ignored by UEFI (to preserve legacy compatibility and allow the legacy BIOS booting behaviour).

Essentially, the text you quoted clearly indicates a desire to ensure that hybrid boot can still be supported.

UEFI could boot from non-GPT anyway, but trying to make legacy BIOS to boot from GPT is a bad idea. Better to just supply two layouts for installations - one for legacy and one for UEFI systems.

Sure - provide two layouts for installations; and always install both of them at the same time so that the end user is able to switch their firmware between BIOS and UEFI (and/or plug the drive/device into a different computer) without breaking everything.


Cheers,

Brendan

[Antti]

Now the implementation is "on hold" until a good compromise is found.

After a short brainstorming session, I'm not sure would I "get over" the inelegancy of the tight coupling of MBR & GPT and the need to have "overlapping" partitions. Let alone the fact that third-party partition software may break this. Currently there are two options (not mutually exclusive, both of these can be provided) on the table:

• Stub code in the MBR that prints "Error: only UEFI booting supported."
• Full code in the MBR that understands GPT.

Both of the these conform to the specification to the letter. The latter felt impossible but maybe it is not. It may ignore legacy partitions (and CHS altogether) and put all effort into finding a bootable partition from GPT. Please note that I'm not claiming that this is the best option. Just thinking aloud...