1

Is there a fundamental difference between a GPT and MBR partition? I'm talking not about the partition table or the layout, I'm talking about a partition itself.

Say I've formatted a partition to NTFS, can I just byte-by-byte copy it across MBR and GPT disks?

If so, if I had a Windows partition, could I copy it byte-by-byte from MBR disk to GPT disk? What would prevent me from slapping an NT 6.0 VBR (aka BOOTMGR) on the partition and chainload it from BIOS grub despite it being on the GPT disk? Same question for a Windows originally installed on the GPT disk. What stops me from doing thus?

  • mbr partitions are usually limited to 2TB. Windows GPT disk AFAIR requires UEFI boot mode (Windows limitation). – Robert Oct 22 '19 at 14:08
  • Thanks for your comment but that's not a fundamental difference :) It's something that happens to be. In fact, I think PC manufacturers should have used the starting CHS address for this purpose if the end CHS address is (0,0,0). That would have gotten them 2^30 * 2TB. – 0fnt Oct 22 '19 at 14:09
5

There’s none. Neither MBR nor GPT deal with what’s inside partitions. You can clone a partition from MBR to GPT and vice versa and still access all the data normally. While staying within limits (like 2^32 max sectors per partition on MBR) of course.

However, when booting and operating systems are involved, things are subject to further limits. Windows has an artificial limitation that means it cannot BIOS-boot from GPT disks. It wants UEFI. Linux is not affected by this limitation. It’s unlikely GRUB will change anything about that.

BIOS-booting doesn’t care about MBR or GPT or whatever anyway. It only executes the first sector of the boot drive.

So what’s stopping you? Windows. Can you make it work anyway? Yes. Just create a compatible boot partition for Windows (FAT32 EFI System Partition for GPT or NTFS normal partition) and use bcdboot to configure it. There’s also mbr2gpt.

  • I get most of what you're saying. But I'm unsure how the artificial limitation works? Let's trace the execution- grub transfers to vbr and enters real mode. Vbr loads bootmgr (likely still in real mode) . Is it here that bootmgr can somehow find out- oh wait I'm on gpt partition but the firmware that started me was legacy so let me stop ? (Not being snide, I know the limit exists, just wondering where). – 0fnt Oct 22 '19 at 19:34
  • Who knows. The BIOS-mode boot code probably has no support for GPT. It can’t even read the BCD and just reboots instantly. – Daniel B Oct 23 '19 at 7:51
  • Sorry I'm not sure about this part. Here's the initial steps. 0. "DISABLE UEFI" in Firmware settings. 1. Install Windows on a BIOS partition. Do things such that Grub chainloads the VBR from Windows partition. 2. Byte-by-byte copy the partition to a GPT disk. 3. Do the same with Grub. Now the question remains, who's stopping the boot process. I'm using the VBR and boomgr which are bios compatible. – 0fnt Oct 23 '19 at 11:29
  • The question does not remain. It cannot be answered. I get the impression that you think the boot process is not concerned with partition tables. It is, even with a VBR. – Daniel B Oct 23 '19 at 13:59
0

The partition tables don‘t care about the data they contain, but the other direction need not be true: partition data may care about the disk and partition table they are contained in.

For example, the boot sector of FAT and NTFS file systems contains a data structure called the BIOS Parameter Block* which contains fields with data like the BIOS** drive number and so-called ‘hidden sectors’, which should contain the partition offset. If you perform a byte-wise copy of the partition to another location, the BPB may be no longer valid. Code in the boot sector and the operating system reading the partition (especially if of the DOS family) may depend on the BPB being filled correctly, so the copied file system might be unbootable or inaccessible on some implementations.

Modern, GPT-aware boot loaders and operating systems will probably not care about these two fields, though; those usually refer to partitions by their UUIDs instead of hardcoded offsets. In particular GRUB, once its core image has been successfully loaded (usually either from the gap before the first partition on an MBR-partitioned disk, or from a BIOS Boot Partition on a GPT-partitioned disk), will access all partitions without using the BPB, regardless of platform.

Nevertheless, in the general case, you cannot assume that file system data does not contain references to the particular partition on the particular disk where it resides.

There may be other problems resulting from bitwise copying; for example, the file system may contain a UUID in its partition data which after bitwise copying will obviously no longer be universally unique, which may break operating systems which assume that it is. This however does not mean you'll be prevented from accessing the partition entirely.


* Here ‘BIOS’ refers not to PC firmware stored in ROM, but to the lower-level I/O subsystem of MS-DOS and PC DOS.

** Here, however, it does refer to PC firmware, in particular to interrupt 0x13 services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.