MBR partition parsing

[Brendan]

Hi,

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...

Let's define "boot manager goals":

• To allow multiple OSs to be installed (e.g. including a "which OS would you like to boot" menu), where some of the OSs that could be installed are legacy OSs that don't support/understand GPT
• To be firmware independent (allow the same device to be booted regardless of whether the firmware is BIOS or UEFI). Note: assume the boot menu lists all OSs installed; where OSs that require UEFI can't be selected if the firmware is BIOS, OSs that require BIOS can't be selected if the firmware is UEFI, and firmware independent OSs can always be selected
• Provide management tools (for testing, diagnostics, boot configuration, etc) that can be used when no OS is installed at all, including tools to manage partitions (create, delete, backup, restore)

The MBR's partition table must (if only temporarily) use MBR partitions to fulfil the first goal (to be able to boot legacy OSs that don't support/understand GPT). Not using MBR partitions (100% compliance with a specification that is likely to be completely irrelevant) is not an option that can be considered.


Cheers,

Brendan

[zaval]

Hi,

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.

but it's obvious, that the uefi idea is that GPT partitioned disks with PMBR should be non bootable by legacy systems. it's seen in many ways:
1) pmbr must contain only 1 partition, marked non bootable
2) it should start at lba 1 and end at the end of disk, leaving no way for any other partitions
3) mbr boot code part must be zeroed

i think it's not coincidentally they mentioned "undefined behavior" there, because what one would expect if legacy bios transfers control to the GPT header? because for bios it would be a "boot sector" of that partition. and again, if you define more than 1 partition, you end up with a fake PMBR and or overlapping partitions. maybe it's acceptable for you and reasonable, but definitely not compliant, and nobody knows how other utilities and loaders which maybe would run on that would take this.

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).



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.

i read that quote as they saying: if you make pmbr partition active, then bios will jump into Gpt header signature which isn't a machine code.

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

only violating the specification and under risk of getting troubles for the user in future. :^)

[BenLunt]

However, not only the value of 0xEE is used. If a value of 0xEF in the MBR's partition entry is used as an ID, the partition entry is meant as Legacy bootable.

Latest specs:
http://www.uefi.org/sites/default/files ... pt%206.pdf (Sections 5.2.1 and 5.2.2.)

Since a Legacy BIOS knows nothing about a GPT, it will execute the code within the first LBA. One of these partitions may point to a partition on the disk, somewhere past LBA 0. This LBA, say LBA X, should contain code to load the OS loader. Since we are booting from a Legacy BIOS, we skipped the GPT, the GPT that we know nothing about, and went right to LBA X and started loading the OS Loader via the code at this VBR.

It just so happens that LBA X is the first sector within a GPT constructed partitioning scheme. However, since the Legacy BIOS knows nothing about it, it doesn't matter.

If the OS is GPT aware, then it will enumerate the other partitions within the GPT, as well as recognize the booted partition as a GPT entry, and will preserve the GPT. However, if the OS is not GPT aware, it might and may overwrite the other partitions including the GPT tables. This is a risk. However, if the OS is not GPT aware, why was a GPT scheme used to begin with? Also, as long as the user does not try to allocate more space on the disk, the GPT is perfectly safe. Only if the user attempts to create other partitions will the GPT be at risk. Since the user is in control, the user should know whether the disk is partitioned via MBR or GPT.

[zaval]

However, not only the value of 0xEE is used. If a value of 0xEF in the MBR's partition entry is used as an ID, the partition entry is meant as Legacy bootable.

Yup, but then:

A legacy MBR may be located at LBA 0 (i.e. the first logical block) of the disk if it is not using the GPT disk layout (i.e., if it is using the MBR disk layout). The boot code on the MBR is not executed by UEFI firmware.

So, the specification clearly means 0xEF won't be used with GPT partitioning.

Since a Legacy BIOS knows nothing about a GPT, it will execute the code within the first LBA. One of these partitions may point to a partition on the disk, somewhere past LBA 0. This LBA, say LBA X, should contain code to load the OS loader. Since we are booting from a Legacy BIOS, we skipped the GPT, the GPT that we know nothing about, and went right to LBA X and started loading the OS Loader via the code at this VBR.

I don't want to be obsessive, but again, how are you going to combine this with a Protective MBR partition, that should have:

StartingLBA Set to 0x00000001 (i.e., the LBA of the GPT Partition
Header).

This only thing is enough to break all those attempts to combine legacy and gpt schemes the compatible way.
Your "magical" legacy partition should sit inside this PMBR partition. Any sane tool could start to whine about broken MBR and even start to "fix" this for the user. Are you sure UEFI implementations you are going to interact with would accept this layout? For them 0xEF partition is Efi System Partition and they would try to load from it, but then your GPT you have here, becomes garbage, uselessly laying around. UEFI won't use it and if it happens that this UEFI will be instructed to operate on partitions somehow, it easily will destroy all GPT. Because for it, MBR with 0xEF is legacy MBR without GPT. It's important.

It just so happens that LBA X is the first sector within a GPT constructed partitioning scheme. However, since the Legacy BIOS knows nothing about it, it doesn't matter.

If the OS is GPT aware, then it will enumerate the other partitions within the GPT, as well as recognize the booted partition as a GPT entry, and will preserve the GPT. However, if the OS is not GPT aware, it might and may overwrite the other partitions including the GPT tables. This is a risk. However, if the OS is not GPT aware, why was a GPT scheme used to begin with? Also, as long as the user does not try to allocate more space on the disk, the GPT is perfectly safe. Only if the user attempts to create other partitions will the GPT be at risk. Since the user is in control, the user should know whether the disk is partitioned via MBR or GPT.

two competing partitioning schemes (whose tools are unaware of each other) with nested partitions in one of the scheme. This is the name of this approach. I guess users of this would be really happy to deal with them. :^)

[Brendan]

Hi,

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.

but it's obvious, that the uefi idea is that GPT partitioned disks with PMBR should be non bootable by legacy systems. it's seen in many ways:
1) pmbr must contain only 1 partition, marked non bootable
2) it should start at lba 1 and end at the end of disk, leaving no way for any other partitions
3) mbr boot code part must be zeroed

i think it's not coincidentally they mentioned "undefined behavior" there, because what one would expect if legacy bios transfers control to the GPT header? because for bios it would be a "boot sector" of that partition. and again, if you define more than 1 partition, you end up with a fake PMBR and or overlapping partitions. maybe it's acceptable for you and reasonable, but definitely not compliant, and nobody knows how other utilities and loaders which maybe would run on that would take this.

You're reading the UEFI specification and then making random assumptions about unrelated things (e.g. "BIOS booting from GPT partitioned disk") that have nothing to do with UEFI or the UEFI specification. It's like reading the specification for the C programming language and then claiming that "Write('Hello, world!')" is not legal in Pascal.

For "UEFI and only UEFI, with GPT and no MBR partitioning at all, and with no BIOS within a 1234 kilometre radius" (the only situation where UEFI spec is 100% appropriate) feel free to follow the UEFI spec to the letter. For hybrid GPT and "BIOS booting from GPT partitioned disk" the UEFI specification is inappropriate (no more than a vague suggestion).


Cheers,

Brendan

[zaval]

Hi,

You're reading the UEFI specification and then making random assumptions about unrelated things (e.g. "BIOS booting from GPT partitioned disk") that have nothing to do with UEFI or the UEFI specification. It's like reading the specification for the C programming language and then claiming that "Write('Hello, world!')" is not legal in Pascal.

Wasn't it you who wanted to make hybrid GPT which should be successfully used by BIOS for boot? If so, why my assumptions are "random"? they aren't even assumptions, I just considered what you said you want to do.
But I agree, trying to make BIOS boot from GPT partitioned disk has nothing to do with UEFI and its specification. And thus most probably in many cases this try will result in something which has nothing to do with a working boot sequence.

For "UEFI and only UEFI, with GPT and no MBR partitioning at all, and with no BIOS within a 1234 kilometre radius" (the only situation where UEFI spec is 100% appropriate) feel free to follow the UEFI spec to the letter. For hybrid GPT and "BIOS booting from GPT partitioned disk" the UEFI specification is inappropriate (no more than a vague suggestion).


Cheers,

Brendan

I agreed earlier on that this easily is appropriate for you. I just noted that it may not work. Unless you will supply "hybrid" UEFI as well.
If you want to use GPT scheme alone, without UEFI and slightly broken, it's normal (mostly ), GPT is a standalone thing despite documented in the UEFI spec.
But this hybrid scheme might not work on UEFI systems. Just because they notice PMBR is invalid. It's neither legacy boot nor valid GPT. they will refuse to work with such a media at all. Is this what you wanna get?

[Brendan]

Hi,

You're reading the UEFI specification and then making random assumptions about unrelated things (e.g. "BIOS booting from GPT partitioned disk") that have nothing to do with UEFI or the UEFI specification. It's like reading the specification for the C programming language and then claiming that "Write('Hello, world!')" is not legal in Pascal.

Wasn't it you who wanted to make hybrid GPT which should be successfully used by BIOS for boot? If so, why my assumptions are "random"? they aren't even assumptions, I just considered what you said you want to do.

For "BIOS booting GPT partitioned disk", the code area of the MBR should be filled with zeros?

But I agree, trying to make BIOS boot from GPT partitioned disk has nothing to do with UEFI and its specification. And thus most probably in many cases this try will result in something which has nothing to do with a working boot sequence.

For "UEFI and only UEFI, with GPT and no MBR partitioning at all, and with no BIOS within a 1234 kilometre radius" (the only situation where UEFI spec is 100% appropriate) feel free to follow the UEFI spec to the letter. For hybrid GPT and "BIOS booting from GPT partitioned disk" the UEFI specification is inappropriate (no more than a vague suggestion).

I agreed earlier on that this easily is appropriate for you. I just noted that it may not work. Unless you will supply "hybrid" UEFI as well.
If you want to use GPT scheme alone, without UEFI and slightly broken, it's normal (mostly ), GPT is a standalone thing despite documented in the UEFI spec.
But this hybrid scheme might not work on UEFI systems. Just because they notice PMBR is invalid. It's neither legacy boot nor valid GPT. they will refuse to work with such a media at all. Is this what you wanna get?

For UEFI there are 2 cases:

• Firmware thinks GPT is valid (despite PMBR not strictly complying with unnecessary restrictions mentioned by the UEFI spec), uses GPT to find the UEFI system partition, and boots from the UEFI system partition.
• Firmware thinks GPT is not valid (due to PMBR not strictly complying with unnecessary restrictions mentioned by the UEFI spec), then looks in the MBR's partition table for a UEFI system partition, and boots from the UEFI system partition if it's found.

To meet the goals of working on both BIOS and UEFI firmware, and working for legacy OSs and OSs that support UEFI, and working for OSs that support GPT and OSs that don't:

• The MBR must contain code to allow the disk to be booted from BIOS; regardless of what UEFI says.
• The MBR's partition table must (at least temporarily) contain the partition/s that a legacy OS needs to work; regardless of what UEFI says.
• The boot manager's code and data (whatever didn't fit in the MBR, and couldn't be in sectors between the MBR and first partition because of GPT) must be somewhere. Because the MBR's partition table must (at least temporarily) contain partition/s anyway; the most logical choice is for the boot manager to have a small partition (marked as "active") in the MBR's partition table. This breaks nothing that didn't already have to be broken. More importantly, if UEFI firmware is going to have a problem with MBR partitions, it means that the user finds out that UEFI firmware is going to have a problem sooner and doesn't end up with unexpected surprises later (if/when the user asks the boot manager to boot a legacy OS that must use partitions in the MBR's partition table).
• For UEFI systems that are fussy about "strict compliance with idiotic and unnecessary nonsense", the MBR's partition table could/should probably also have an entry for the UEFI system partition.
• For the majority of UEFI systems (that are not fussy about "strict compliance with idiotic and unnecessary nonsense"), the GPT's partition table should have an entry for the UEFI system partition.
• For the MBR's partition table; any space that is not used by a partition mentioned in the MBR should be marked as "not unused" using the 0xEE partition type, for no reason other than to protect GPT's partitions from legacy OSs (that don't support GPT).
• All actual partitions (excluding fake "type 0xEE" partition/s in the MBR) should be mentioned in GPT (regardless of whether they also had to be mentioned by MBR or not) to ensure that OSs that support/use GPT work properly.

If all of the above is done; then it might not work for an extremely small number of dodgy computers that aren't worth caring about. If one of the things above is not done; then it might not work for a larger number of computers and that's far more important.


Cheers,

Brendan

[Octocontrabass]

Let's define "boot manager goals":

• To allow multiple OSs to be installed (e.g. including a "which OS would you like to boot" menu), where some of the OSs that could be installed are legacy OSs that don't support/understand GPT

Do you actually want a boot manager that can boot OSes that don't support GPT from a GPT disk, or are you arguing for the sake of arguing? Can you think of any situation where this would be better than running the legacy OS in a virtual machine?

Let's take a look at what happens when you remove this requirement. For a MBR disk, you use boot code similar to the "standard" MBR, and one of the four partition table entries is the EFI system partition. For a GPT disk, you use boot code that can parse GPT in the protective MBR, and one of the GPT partitions is the EFI system partition. This supports all four combinations of partition table and firmware without needing any "clever" tricks that might confuse the firmware into misbehaving.

[Brendan]

Hi,

Let's define "boot manager goals":

• To allow multiple OSs to be installed (e.g. including a "which OS would you like to boot" menu), where some of the OSs that could be installed are legacy OSs that don't support/understand GPT

Do you actually want a boot manager that can boot OSes that don't support GPT from a GPT disk, or are you arguing for the sake of arguing? Can you think of any situation where this would be better than running the legacy OS in a virtual machine?

The idea would be to have any number of partitions described by GPT; where the boot manager lists whatever OSs are installed and lets the user select one. If the computer was booted by BIOS and the user selects a legacy OS that doesn't support GPT, then the boot manager modifies the MBR's partition table to suit, and then starts the legacy OS. The legacy OS (that doesn't support GPT) sees the "normal MBR partitions" that it expects, and therefore should work fine without any problem. Later (when the computer is rebooted, if the same legacy OS isn't selected) the boot manager restores the MBR so that no other OS sees anything different.

I refuse to build a virtual machine/hypervisor into the MBR (and all the complexity and bloat that entails) for no sane reason whatsoever.

Let's take a look at what happens when you remove this requirement. For a MBR disk, you use boot code similar to the "standard" MBR, and one of the four partition table entries is the EFI system partition.

..and in this case it fails to work correctly for my OS (which will expect GPT) and ends up limited to the "max. of 4 primary partitions" that makes it unable to allow very many OSs to be installed on the same disk; essentially making it a crippled piece of trash for this case.

For a GPT disk, you use boot code that can parse GPT in the protective MBR, and one of the GPT partitions is the EFI system partition. This supports all four combinations of partition table and firmware without needing any "clever" tricks that might confuse the firmware into misbehaving.

..and for BIOS the amount of code needed in the <440 bytes of the MBR to correctly check and parse GPT (and find the UEFI system partition, and support FAT, and load the remainder of it's own code and data from there, and handle all possible errors in an acceptable manner) makes it "extremely impractical" and/or impossible and/or a crippled piece of trash.

Of course for UEFI, you've got code in the MBR that is supposed to be full of zeros so it's still not 100% compliant with UEFI's idiotic and unnecessary requirements; so you've made it a crippled piece of trash for multiple cases for almost no useful reason.


Cheers,

Brendan

[Octocontrabass]

I refuse to build a virtual machine/hypervisor into the MBR (and all the complexity and bloat that entails) for no sane reason whatsoever.

Who suggested anything as insane as that? I was referring to using a virtual machine inside another OS, on the assumption that any OS not supporting GPT is old enough that it shouldn't be running on the same hardware as a modern OS anyway.

..and in this case it fails to work correctly for my OS (which will expect GPT)

Congratulations, you only have to worry about two combinations instead of four.

and ends up limited to the "max. of 4 primary partitions" that makes it unable to allow very many OSs to be installed on the same disk;

You can install operating systems on extended partitions. The only reason people usually don't is because the "standard" MBR can't load them. A boot manager has no such limitation. (And besides, how many people ever install more than one operating system on a single computer?)

..and for BIOS the amount of code needed in the <440 bytes of the MBR to correctly check and parse GPT (and find the UEFI system partition, and support FAT, and load the remainder of it's own code and data from there, and handle all possible errors in an acceptable manner) makes it "extremely impractical" and/or impossible and/or a crippled piece of trash.

Or you can chainload the partition with the "legacy BIOS bootable" attribute.

Of course for UEFI, you've got code in the MBR that is supposed to be full of zeros so it's still not 100% compliant with UEFI's idiotic and unnecessary requirements; so you've made it a crippled piece of trash for multiple cases for almost no useful reason.

Who says it's full of zeroes? The UEFI specification explicitly gives you 440 contiguous bytes for legacy BIOS boot code.

[Brendan]

Hi,

I refuse to build a virtual machine/hypervisor into the MBR (and all the complexity and bloat that entails) for no sane reason whatsoever.

Who suggested anything as insane as that? I was referring to using a virtual machine inside another OS, on the assumption that any OS not supporting GPT is old enough that it shouldn't be running on the same hardware as a modern OS anyway.

What other OS?

You wipe the disk clean so that nothing is on it; then install the boot manager, check it boots OK, and then use the boot manager's tools to create a new partition for FreeDOS. Then you install FreeDOS in that new partition. There are no other OSs installed, so which OS is the virtual machine running on at this point?

Later you decide to create a partition for my OS (which expect GPT) and install my OS, and play around with that for a while. Then you decide to boot FreeDOS again. My OS doesn't have any virtual machine, so which OS is the virtual machine (that's used to run FreeDOS) running on at this point?

..and in this case it fails to work correctly for my OS (which will expect GPT)

Congratulations, you only have to worry about two combinations instead of four.

My OS only has to worry about 2 combinations. My boot manager (which should never be part of any OS) still has to worry about all 4 combinations.

and ends up limited to the "max. of 4 primary partitions" that makes it unable to allow very many OSs to be installed on the same disk;

You can install operating systems on extended partitions. The only reason people usually don't is because the "standard" MBR can't load them. A boot manager has no such limitation. (And besides, how many people ever install more than one operating system on a single computer?)

The number of legacy OSs (that don't/can't support GPT) that are able to boot from extended partitions is approximately zero; and this has nothing to do with the MBR and everything to do with the OS's boot loader, installer, etc.

A lot of people don't even know it's possible to install multiple OSs, which makes it harder to get them to install/try out a different OS. For my case (an OS designed for multiple computers) it gets worse; especially if they can't dual boot (e.g. use Windows on a computer most of the time, but then boot my OS to add that computer to the cluster whenever they aren't using Windows).

..and for BIOS the amount of code needed in the <440 bytes of the MBR to correctly check and parse GPT (and find the UEFI system partition, and support FAT, and load the remainder of it's own code and data from there, and handle all possible errors in an acceptable manner) makes it "extremely impractical" and/or impossible and/or a crippled piece of trash.

Or you can chainload the partition with the "legacy BIOS bootable" attribute.

Erm, OK; the MBR correctly checks and parses GPT, finds the UEFI system partition, uses its own FAT support to load the remainder of it's own code and data from the UEFI system partition, displays a nice graphical boot menu and waits for the user to select an OS to boot; then (after several million lines of code have been executed that did not fit in the MBR) the boot manager chain-loads the selected OS from one of the partitions that happened to have the "legacy BIOS bootable" attribute.

Of course for UEFI, you've got code in the MBR that is supposed to be full of zeros so it's still not 100% compliant with UEFI's idiotic and unnecessary requirements; so you've made it a crippled piece of trash for multiple cases for almost no useful reason.

Who says it's full of zeroes? The UEFI specification explicitly gives you 440 contiguous bytes for legacy BIOS boot code.

The UEFI spec says that (for GPT partitioned disks being booted by UEFI and not BIOS) those ~440 bytes "must" be zero. This is part of why I've been calling UEFI's requirements "idiotic and unnecessary" (if you plan use GPT and support both BIOS and UEFI, then the MBR's code must be zero and non-zero at the same time).


Cheers,

Brendan

[Neutron]

..and for BIOS the amount of code needed in the <440 bytes of the MBR to correctly check and parse GPT (and find the UEFI system partition, and support FAT, and load the remainder of it's own code and data from there, and handle all possible errors in an acceptable manner) makes it "extremely impractical" and/or impossible and/or a crippled piece of trash.

Or you can chainload the partition with the "legacy BIOS bootable" attribute.

Erm, OK; the MBR correctly checks and parses GPT, finds the UEFI system partition, uses its own FAT support to load the remainder of it's own code and data from the UEFI system partition, displays a nice graphical boot menu and waits for the user to select an OS to boot; then (after several million lines of code have been executed that did not fit in the MBR) the boot manager chain-loads the selected OS from one of the partitions that happened to have the "legacy BIOS bootable" attribute.

You could do what GRUB does: in the BIOS/GPT case the MBR boot sector looks for a "BIOS boot partition" containing the next stage.

[zaval]

Hi,

The UEFI spec says that (for GPT partitioned disks being booted by UEFI and not BIOS) those ~440 bytes "must" be zero. This is part of why I've been calling UEFI's requirements "idiotic and unnecessary" (if you plan use GPT and support both BIOS and UEFI, then the MBR's code must be zero and non-zero at the same time).


Cheers,

Brendan

This requirement is not that idiotic. Protective MBR partition isn't really a partition, it's a shield, it cannot have real boot sector (because there GPT header resides); so the only way might be to allow to let the MBR code be present but it must not be using PMBR, being aware of its real role, and working with gpt partitions. But there is no "active" indicator inside gpt partition array, so it's hard to imagine what meaningful that MBR code could do with all those partitions. Since MBR code is for all possible installations on a disk and not just for one, it should be able to pick any. Suppose there is 128 partitions on a disk, how MBR code should pick one? The maximum it could, is enumerate them and ask user what he/she wants to boot from. And what to do if there is no interaction with user, try one by one? But not every partition contains a valid boot sector with proper code... I don't know if it's possible to encode all this functionality into 440 bytes. Of course they might allow "protective" boot sector or even block of sectors, that would precede GPT header, and might contain more sophisticated code to work with GPT Partition Array. Probably they didn't do that because they weren't obsessed with BIOS and wanted to help it become a history, not prolonging its usage.

You could do what GRUB does: in the BIOS/GPT case the MBR boot sector looks for a "BIOS boot partition" containing the next stage.

but this rejects the main advantage of GPT - provide as many bootable partitions as one wants and his/her disk is able to fit.

[Octocontrabass]

You wipe the disk clean so that nothing is on it; then install the boot manager, check it boots OK, and then use the boot manager's tools to create a new partition for FreeDOS. Then you install FreeDOS in that new partition. There are no other OSs installed, so which OS is the virtual machine running on at this point?

Later you decide to create a partition for my OS (which expect GPT) and install my OS, and play around with that for a while. Then you decide to boot FreeDOS again. My OS doesn't have any virtual machine, so which OS is the virtual machine (that's used to run FreeDOS) running on at this point?

Which PC is powerful enough to run your OS and also old enough that it makes sense to install FreeDOS as an everyday OS instead of using Windows or Linux with DOSBox?

The number of legacy OSs (that don't/can't support GPT) that are able to boot from extended partitions is approximately zero; and this has nothing to do with the MBR and everything to do with the OS's boot loader, installer, etc.

And your boot manager is in exactly the position to fix that. For example, Windows NT has no trouble booting from an extended partition, but the installer will only install onto primary partitions. Your boot manager is in the perfect position to shuffle primary and extended partitions to make it work.

A lot of people don't even know it's possible to install multiple OSs, which makes it harder to get them to install/try out a different OS. For my case (an OS designed for multiple computers) it gets worse; especially if they can't dual boot (e.g. use Windows on a computer most of the time, but then boot my OS to add that computer to the cluster whenever they aren't using Windows).

A lot of people don't care. You must have some lofty goals with your OS if you think you'll ever convince the average user to attempt to install it (instead of paying someone else to do it, or buying a new computer with your OS preinstalled, or receiving a company laptop with your OS installed by the IT department).

Erm, OK; the MBR correctly checks and parses GPT, finds the UEFI system partition, uses its own FAT support to load the remainder of it's own code and data from the UEFI system partition, displays a nice graphical boot menu and waits for the user to select an OS to boot; then (after several million lines of code have been executed that did not fit in the MBR) the boot manager chain-loads the selected OS from one of the partitions that happened to have the "legacy BIOS bootable" attribute.

Uhh, okay. Or you could have the "legacy BIOS bootable" partition be like a second stage for your MBR. You don't even have to use the "legacy BIOS bootable" attribute - I only suggested it because UEFI leaves its purpose undefined. If you prefer, you can search for the GUID for your MBR's second stage instead of using the attribute. The MBR parses GPT, finds its second stage partition, loads and jumps to it, and the second stage is responsible for the rest (finding the UEFI system partition, using its own FAT support to load the remainder of the code and data, displaying the graphical boot menu, and loading the selected OS).

The UEFI spec says that (for GPT partitioned disks being booted by UEFI and not BIOS) those ~440 bytes "must" be zero.

Which UEFI spec have you been looking at? Maybe I'm missing something, but none of the specs I've looked at seem to say anything about those 440 bytes being zero. All I see is that those bytes are "boot code" and "unused by UEFI systems".

[Brendan]

Hi,

You wipe the disk clean so that nothing is on it; then install the boot manager, check it boots OK, and then use the boot manager's tools to create a new partition for FreeDOS. Then you install FreeDOS in that new partition. There are no other OSs installed, so which OS is the virtual machine running on at this point?

Later you decide to create a partition for my OS (which expect GPT) and install my OS, and play around with that for a while. Then you decide to boot FreeDOS again. My OS doesn't have any virtual machine, so which OS is the virtual machine (that's used to run FreeDOS) running on at this point?

Which PC is powerful enough to run your OS and also old enough that it makes sense to install FreeDOS as an everyday OS instead of using Windows or Linux with DOSBox?

Who says it's an everyday OS? Why does it matter which OS it is? Why does how powerful the computer is matter?

The simple fact is that if there's no virtual machine you can't use a virtual machine; so "just run the legacy OS in a virtual machine" is not a sane solution.

Note: My OS is designed to work fine on an old 25 MHz 80486 with no FPU; it's just that (if there's user/s) you might need a pool of many old/slow computers (or a newer/faster computer somewhere on the network) to get acceptable performance from the GUI.

A lot of people don't even know it's possible to install multiple OSs, which makes it harder to get them to install/try out a different OS. For my case (an OS designed for multiple computers) it gets worse; especially if they can't dual boot (e.g. use Windows on a computer most of the time, but then boot my OS to add that computer to the cluster whenever they aren't using Windows).

A lot of people don't care. You must have some lofty goals with your OS if you think you'll ever convince the average user to attempt to install it (instead of paying someone else to do it, or buying a new computer with your OS preinstalled, or receiving a company laptop with your OS installed by the IT department).

A lot of people is not everybody. For a variety of reasons, (some) people do dual boot OSX and Windows; or dual boot Linux and Windows; or triple boot OSX, Windows and Linux; or...

Erm, OK; the MBR correctly checks and parses GPT, finds the UEFI system partition, uses its own FAT support to load the remainder of it's own code and data from the UEFI system partition, displays a nice graphical boot menu and waits for the user to select an OS to boot; then (after several million lines of code have been executed that did not fit in the MBR) the boot manager chain-loads the selected OS from one of the partitions that happened to have the "legacy BIOS bootable" attribute.

Uhh, okay. Or you could have the "legacy BIOS bootable" partition be like a second stage for your MBR. You don't even have to use the "legacy BIOS bootable" attribute - I only suggested it because UEFI leaves its purpose undefined. If you prefer, you can search for the GUID for your MBR's second stage instead of using the attribute. The MBR parses GPT, finds its second stage partition, loads and jumps to it, and the second stage is responsible for the rest (finding the UEFI system partition, using its own FAT support to load the remainder of the code and data, displaying the graphical boot menu, and loading the selected OS).

The MBR attempts to parse GPT, then crashes because decent code (with acceptable error handling, etc) can't fit in ~440 bytes, or crashes because poor quality code did fit in ~440 bytes.

The UEFI spec says that (for GPT partitioned disks being booted by UEFI and not BIOS) those ~440 bytes "must" be zero.

Which UEFI spec have you been looking at? Maybe I'm missing something, but none of the specs I've looked at seem to say anything about those 440 bytes being zero. All I see is that those bytes are "boot code" and "unused by UEFI systems".

To be honest, I wasn't reading any UEFI spec properly (I've checked multiple versions now, and think you're right). It was zaval that said mbr boot code part must be zeroed (and I failed to check ).


Cheers,

Brendan