mbrpartitioning
A quick point of clarification needed. With the MBR
Maketecheasier.com says
each partition can only go up to a maximum of 2TB in size
The Differences Between MBR and GPT
But IBM's Developerworks says
The MBR layout also limits the maximum size of disk that is supported
to approximately 2TB
Learn Linux, 101 : Hard disk layout
Which is correct?
*cross posted on stackoverflow
There's no need to regress to the MBR partitioning scheme, nor even any need for a "hybrid MBR" partitioning scheme. (I have such on one of my machines, and attest that they are not for the fainthearted.)
Windows 7 can use EFI-partitioned discs just fine. It just cannot be bootstrapped from them on non-EFI machines, and (to protect you from yourself, in Microsoft fashion) refuses to install on them in the first place. In your case, your problem is a fundamental deficiency of your firmware, and isn't really a Windows issue at all. Your firmware doesn't understand the EFI partition table.
Such understanding is necessary if one wants to convert one's operating system bootstrap to be on EFI partitioned discs. One's firmware needs to know to put up the EFI Boot Manager menu, and then load the selected operating system loader program from the EFI System Partition. Your firmware isn't very smart, though, and doesn't know how to do much more than load the "master boot record" and run its bootstrap code. On an EFI partitioned disc there's no code in the "master boot record" to crank through the rest of the EFI boot process.
At best, right now, you have MBR bootstrap code that is equally as ignorant of the EFI partition table scheme as your firmware, and that's expecting to find and process an MBR partition table. What you need is two things:
The first is not impossible. There are two sources of such EFI-partitioning-aware MBR bootstraps:
Both will look for the "active" partition, and load and run its VBR, effectively bootstrapping in the old PC/AT and PC98 way but with an EFI partition table. Failing those two, the best alternatives that you'll get right now are:
The second (persuading Windows 7 to install on an EFI partitioned disc) is achievable, with the x86-64 flavour of Windows 7 at least. It's complex, not officially supported by Microsoft, and requires making what is effectively your own Windows installation disc with the EFI version of Microsoft's Boot Manager on it, and running that from within an EFI boot environment somehow. (If you have UEFI DUET installed, this is fairly easy, of course.) But it convinces Windows 7 that it its installer was bootstrapped on an EFI system, which criterion the installer uses to determine whether it will allow Windows to be installed on an EFI partitioned hard disc.
Of course, there's the additional, final, complexity of, once installed, bootstrapping Windows 7 from day to day; because the installer, knowing that you have EFI firmware, will have installed the EFI version of Microsoft's Boot Manager. You'll thus need either:
Pretty much all of this nonsense just goes away if one has EFI firmware in the first place. Windows 7 (x86-64) will install happily, and an EFI Boot Manager that understands the EFI partition table and that will load and run Microsoft's Boot Manager (as well as any other EFI-bootable operating system) directly from its ordinary program image file in the EFI System Partition, comes with the firmware.
It looks like something has trashed your GPT data -- both the main data structures and the backup data structures. I don't know specifically what might have done this, but a buggy partitioning tool seems like the most likely culprit. Another possibility is that there's been some confusion over something like a RAID configuration -- if the disk was originally prepared with your motherboard's RAID features active and then accessed with the RAID features inactive, something like this might have happened.
Two options seem most reasonable at this point:
gdisk to create a partition that begins at that point and that ends at the last possible sector. This stands a good chance of succeeding, but there's a risk that if your original partition did not start at sector 2048, you could end up damaging it when you try to access the new partition. Also, some tools will try to create a new filesystem when you create a new partition, so using them would be risky at best. (I recommended gdisk for this task because it does not touch the partitions' contents, just the partition table that defines them.) Also, if the disk held an EFI System Partition in addition to the main data partition, the main data partition would not begin at sector 2048.Take your pick as to the approach, and good luck! Whatever you do, though, be cautious. You might consider doing a raw disk backup to a spare disk, if you've got one that's big enough to hold all your data. If you do this, though, be very careful in specifying the source and destination disks, or your backup could end up trashing the data you intend to save!
Best Answer
Each partition cannot be longer than 2TB. This is because 2TB (roughly) is the maximum size that can be specified by to bytes 9 through 12, which is the starting sector in LBA format. Then, bytes 13-16 can specify the size, which must be 4,294,967,295 sectors or smaller, which is 2,199,023,255,040 bytes if each sector is 512 bytes (which was the most widely supported standard size for a sector, throughout the time when MBRs were regularly used). 2TB is 2,199,023,255,552 bytes, so the actual limit (with standard sized sectors) is 2TB - 512 bytes. Assuming we accept that approximation, MakeTechEasier.com's claim (mentioned in the question) is correct.
Then, bytes 13-16 of the MBR can specify the size, which similarly must be 2,199,023,255,040 or smaller (making the same assumptions about sector sizes). So the actual limit of what an MBR can specify (using the most common standards) is 4TB - 1KB.
However, a person could not have 4 partitions that are 1TB each, because starting on the 3rd partition would not be possible. That is too confusing for easy marketing, so people generally just refer to 2TB as the limit before potential problems could creep into the mixture. To, to keep the story simple, IBM's Developerworks is probably just saying what is recommended for businesses who just want things to work well, without experiences inconveniences from new limits to keep track of when trying to squeeze out every possible bit. It's far simpler to say: MBR=up to 2TB=okay, bigger is supported by GPT.
Note that the limits I'm referring to are just referring to the values that are stored in the disk structures. I'm not making any particular statements about support by various operating systems or BIOS implementations. Software might use a "signed" number to keep track of things. Such software code would effectively be more likely to have a 2TB limit than a 4TB limit. The idea of having a disk space that is usable by a partition, but which is not able to be the starting location of a partition, might violate some basic assumptions by certain software (like the "fdisk" disk partitioner, and the "setup" operating system's installer), etc. So IBM's statement may also have been trying to describe the likely experience, taking into account the complexity caused by a need to be supported by disk limitations (how much data fits in a certain amount of space), operating systems (including drivers for certain disks), and BIOS implementations. Although the limit stated by IBM can theoretically be worked around, via software, the provided information may be the right advice for someone who wants to avoid problems.