Skip the MBR

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:
Contact Brendan

Re: Skip the MBR

Post by Brendan »

Hi,

Think of it like this:
  • GPT only: Software that supports GPT (including UEFI) checks for a valid Primary GPT Header and ignores the MBR. Software that doesn't support GPT only sees the protective MBR which says "don't touch anything" (to protect GPT from being messed up).
    MBR only: Software that supports GPT (including UEFI) checks for a valid Primary GPT Header and doesn't find one; and normal software (but not UEFI) may fall back to "MBR only mode" in that case. Software that doesn't support GPT sees a valid MBR partition table.
    "Hybrid GPT+MBR": Software that supports GPT (including UEFI) checks for a valid Primary GPT Header and ignores the MBR. Software that doesn't support GPT sees a valid MBR partition table.
The only problem with "hybrid GPT+MBR" is ensuring that the MBR and GPT are consistent. This mostly only means that utilities that create/modify partitions need to be aware that it is a "hybrid GPT+MBR" scheme. Any software (including UEFI and BIOS firmware) that only mounts/uses partitions doesn't really need to know or care - it can safely use either partitioning, although software that uses the MBR's partitions will be effected by its limitations (only 4 primary partitions, partitions limited to 2 TiB).

Of course partitions are rarely changed; and when they are it's not too inconvenient for the user to use a partitioning utility that understands "hybrid GPT+MBR", even if that utility is not part of the OS they're using (or planning to install).

More importantly; if you're designing some sort of boot manager, then (at least in my opinion) it would make sense to include a partitioning utility that can be used if/when there is no OS installed, especially if you're planning to support "hybrid GPT+MBR" (as it ensures the user does have a suitable partitioning utility they can use, in case their OS only supports MBR partitioning or only supports GPT).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Top
embryo

Re: Skip the MBR

Post by embryo »

Brendan wrote:Think of it like this:
  • GPT only: Software that supports GPT (including UEFI) checks for a valid Primary GPT Header and ignores the MBR. Software that doesn't support GPT only sees the protective MBR which says "don't touch anything" (to protect GPT from being messed up).
    MBR only: Software that supports GPT (including UEFI) checks for a valid Primary GPT Header and doesn't find one; and normal software (but not UEFI) may fall back to "MBR only mode" in that case. Software that doesn't support GPT sees a valid MBR partition table.
    "Hybrid GPT+MBR": Software that supports GPT (including UEFI) checks for a valid Primary GPT Header and ignores the MBR. Software that doesn't support GPT sees a valid MBR partition table.
But still I want to clarify some things. I see it like this:
  • 1) We have a legacy computer and a disk (or USB stick) with legacy MBR.
    Here we expect the standard legacy booting sequence.
  • 2) We have a legacy computer and disk (or USB stick) with UEFI-driven first sectors.
    Here we can have two variants of MBR - protective or legacy with UEFI partition only. The protective MBR most probably contains some code that displays a UEFI incompatibility warning message to the user. And the legacy MBR with UEFI partition (I suppose) should do the same. In both cases the media is not bootable without UEFI. But if we are those who are responsible for writing the zero sector's MBR then we can place in it any useful code to detect such situation and next to load some legacy bootloader.
  • 3) We have UEFI compliant computer and a disk (or USB stick) with legacy MBR.
    Here the BIOS can not find neither a protective MBR nor a legacy with UEFI partition. So, it can behave according to the expectations of legacy OS support and just start the code from legacy MBR. But would it support the legacy booting or not is an open question.
  • 4) We have UEFI compliant computer and a disk (or USB stick) with UEFI-driven first sectors.
    Here the standard UEFI boot sequence will take place and I see no any additional problem.
If we make a summary of the variants above then we can see that in cases when there is a computer with UEFI support it is better to have standard UEFI-defined first sectors. And in case if we have a legacy computer it is possible to use any of the UEFI variants with protective MBR or legacy MBR with UEFI partition, but to write a legacy booting code in those MBRs.

So, if the scheme from the summary is implemented, then we can safely boot on UEFI system and if there is a legacy system then the legacy support code from zero sector MBR will be run and it can then start some more specific legacy loader (and it can't start UEFI loader because there is no UEFI compliant BIOS that supports UEFI API).
Brendan wrote:The only problem with "hybrid GPT+MBR" is ensuring that the MBR and GPT are consistent. This mostly only means that utilities that create/modify partitions need to be aware that it is a "hybrid GPT+MBR" scheme. Any software (including UEFI and BIOS firmware) that only mounts/uses partitions doesn't really need to know or care - it can safely use either partitioning, although software that uses the MBR's partitions will be effected by its limitations (only 4 primary partitions, partitions limited to 2 TiB).
If I see it correctly, your message tells us just the same as I have told above, but with different words.
Brendan wrote:More importantly; if you're designing some sort of boot manager, then (at least in my opinion) it would make sense to include a partitioning utility that can be used if/when there is no OS installed, especially if you're planning to support "hybrid GPT+MBR" (as it ensures the user does have a suitable partitioning utility they can use, in case their OS only supports MBR partitioning or only supports GPT).
A partitioning utility is a very useful tool not only in case of a bootloader. If we boot from a USB stick then after system is loaded we can see that it is the right time to change something on the hard drive, or to install the system from USB, or to prepare the disk for another OS, or whatever else. So, at least if we boot from a USB, then the partitioning utility is a must have, but also the file system support is also very welcome.
Top
Post Reply

Return to “OS Development”