Why can't we use a 'fake' MBR to bypass the 2.2TiB BIOS limitation?

[eton975]

In case you're not familiar, MBR-partitioned disks can't be larger than 2.2 TiB because the standard doesn't support more than 2^32 512 byte sectors. This isn't a problem for purely data disks, because by the time they're being used the OS is already loaded and supports GPT disks. But for bootdisks, the BIOS needs to be able to recognize a bootable MBR.

We use OS-level tools like Seagate DiscWizard to partition larger disks into a 2.2TiB partition + a partition that takes up the rest of the disk.

But why can't we use a 'fake' MBR that contains a tiny partition with a bootloader? Then the rest of the disk is partitioned as GPT.

So instead of things going like this:

BIOS reads MBR which says disk is 2.2TiB > BIOS executes bootloader > bootloader starts OS and hands over computer to it > OS runs on 2.2TiB partition.

Couldn't they go like this?

BIOS reads MBR which says disk is tiny (<100MB), but contains a special bootloader > executes bootloader > bootloader has UEFI functions built in and treats rest of disk as GPT > boots OS from GPT partition > OS sees entire disk as one partition, minus 100MB.

Is there a reason we don't do this?

 

[RecoveryForce]

Why would you want to, unless you are still running Windows 98 or XP? Boot managers of the past resulted in a lot of unnecessary headaches and data loss.

 

[eton975]

Why would you want to, unless you are still running Windows 98 or XP? Boot managers of the past resulted in a lot of unnecessary headaches and data loss.

If you're using a motherboard that doesn't support UEFI?

 

[RecoveryForce]

Most of my system boards here at the lab pre-exist UEFI, but they support GPT, to the best of my knowledge.

I believe you need GPT to use UEFI, but don't need UEFI to use GPT.

 

[eton975]

Most of my system boards here at the lab pre-exist UEFI, but they support GPT, to the best of my knowledge.

I believe you need GPT to use UEFI, but don't need UEFI to use GPT.

That seems to go against everything I've heard so far... EDIT: at least when it comes to Windows. I think Linux distros can do GPT from BIOS.

BTW... how are the Toshiba DT01ACA300s compared to the ST3000DM001 and WD 3TB drives in terms of quality? Curious because I plan to be buying one soon after hearing about the ST3000DM001 failure rates but I dunno if the Toshy's a good drive. How do they tend to fail?

 

[therealnickdanger]

I believe you need GPT to use UEFI, but don't need UEFI to use GPT.

I believe that the key here is "bootable". My Q6600 machine on DG965WH board with no UEFI has no problem running GPT on my 3TB, 4TB, and 5TB drives - but those drives are not boot drives. For the last 6 years all my machines have been running SSD boot drives or leftover smaller HDDs, so I haven't had to worry about the size restriction enough to test it.

 

[zir_blazer]

Linux can do BIOS-GPT, it works exactly as described: A sort of GPT Driver as Boot Loader in a MBR area. Windows supports ONLY BIOS-MBR in both 32 and 64 Bits, or UEFI-GPT on 64 Bits. On Linux, you can actually do a sort of hybrid with GPT, and boot either in either BIOS or UEFI Mode with the same install.

 

[Phynaz]

Most of my system boards here at the lab pre-exist UEFI, but they support GPT, to the best of my knowledge.

I believe you need GPT to use UEFI, but don't need UEFI to use GPT.

You have that backwards. You need UEFI to boot Windows from a GPT disk.

 

[R0H1T]

That seems to go against everything I've heard so far... EDIT: at least when it comes to Windows. I think Linux distros can do GPT from BIOS.

BTW... how are the Toshiba DT01ACA300s compared to the ST3000DM001 and WD 3TB drives in terms of quality? Curious because I plan to be buying one soon after hearing about the ST3000DM001 failure rates but I dunno if the Toshy's a good drive. How do they tend to fail?

Not true ~

https://superuser.com/questions/630833/how-to-install-windows-on-gpt-disk-without-uefi-bios
https://superuser.com/questions/297776/windows-on-a-hybrid-mbr-gpt/298960#298960
http://rodsbooks.com./bios2uefi/index.html
http://www.plop.at/en/bootmanager/full.html#runflp

Complicated but (probably) can be done, I tried Rod Smith's method but couldn't get it to work with win8, unfortunately Linux isn't my strong suit so I abandoned the idea after two failed attempts.

 

[ArisVer]

If you're using a motherboard that doesn't support UEFI?

Just use a less than 2TB boot disk.

 

[bononos]

In case you're not familiar, MBR-partitioned disks can't be larger than 2.2 TiB because the standard doesn't support more than 2^32 512 byte sectors. This isn't a problem for purely data disks, because by the time they're being used the OS is already loaded and supports GPT disks. But for bootdisks, the BIOS needs to be able to recognize a bootable MBR.

We use OS-level tools like Seagate DiscWizard to partition larger disks into a 2.2TiB partition + a partition that takes up the rest of the disk.

But why can't we use a 'fake' MBR that contains a tiny partition with a bootloader? Then the rest of the disk is partitioned as GPT.
......

Gigabyte's hybrid UEFI 'bios' is another way. It can boot 3+tb disks without having UEFI on those motherboards.

 

[mv2devnull]

You have that backwards. You need UEFI to boot Windows from a GPT disk.

Note though that boot loader and OS are separate entities. Particularly on multi-boot scenarios one can have multiple boot managers and the first chainloads the next rather than loading the (foreign) OS directly. Shifting between UEFI and legacy is not possible on the fly, AFAIK.

Nevertheless, the boot process has many players:
1. How the firmware can load and execute a bootloader. BIOS loads from sector 0, while UEFI can read the (FAT32) EFI System Partiiton of GPT disk.

2. What partition tables and filesystems the bootloader can read OS kernel from.

3. What partition tables and filesystems the OS kernel does support for the root/boot partition.


I had a dual-boot for a while. UEFI on motherboard, GPT on SSD. UEFI did boot the Windows. A Linux distro, however, had a legacy boot loader that did not support "new stuff". The GPT did contain a "fake MBR" so that when the firmware did load "in legacy mode" first part of bootloader from sector 0, the part did find the partition that had rest of the bootloader and Linux kernel. The kernel in turn was able to find the root partition based on GPT's information.


The SSD are one of the reasons why there is little pressure for booting from 2+TB MBR.

 

[Dufus]

But why can't we use a 'fake' MBR that contains a tiny partition with a bootloader? Then the rest of the disk is partitioned as GPT.

GPT already uses a fake MBR called a protective MBR. You can add loader code to this but if you add more than just the protective partition to the partition table Windows gets upset.

BIOS reads MBR which says disk is 2.2TiB > BIOS executes bootloader > bootloader starts OS and hands over computer to it > OS runs on 2.2TiB partition.

BIOS does not read disk size from MBR, it reads partition sizes and placement. Only 4 bytes are allocated for offset and 4 bytes for size in the partition table. It is the partition table format that holds the size back, legacy BIOS itself has been able to read much more than this since well before EFI came on the scene.

BIOS reads MBR which says disk is tiny (<100MB), but contains a special bootloader > executes bootloader > bootloader has UEFI functions built in and treats rest of disk as GPT > boots OS from GPT partition > OS sees entire disk as one partition, minus 100MB.

Is there a reason we don't do this?

Yes, because Windows will use the legacy loader and also read the disks partition table and not be happy with it. Well that's how it turned out for me while trying. Technically if the OS co-operated it should be doable.

A way around it though is to have a second disk with MBR and loader then that can be used to chain boot a GPT disk on which the Windows OS resides.

Disk 1 is a GPT disk with dual W7 and W8 where W7 has been booted (C: drive) and recognized by the OS as GPT while using an old legacy board with no EFI.