It started with my very highly customised install needing more space: http://forums.linuxmint.com/viewtopic.php?f=46&t=117435. Now that I have the drive up and running, I need to move around a partition. I tried to get the partition to move to the end of the drive using GParted, but hit the 2TB MBR wall. Is there a way to make this work without blanking the drive and erasing all my data? IF you look at the screenshot, you'll see 564GiB free space to the right. I want to move sda3 to the right to give the full sda4 some breathing space.

That disk already has over 2TiB of partitions on it. Ordinarily, that's not possible with the Master Boot Record (MBR) partitioning system; however, some tools do let you take advantage of quirks in the MBR definition and create up to 4TiB worth of partitions on such disks so long as the last partition begins before the 2TiB mark. Your disk satisfies this rule, so it's conceivable this is what you've got. To verify this, please examine the output of:

If you get a line that reads "Partition Table: gpt", then my hypothesis is incorrect and you should ignore the rest of this message; instead, post back with more details about what happens in GParted when you try to resize your partition.

If the line reads "Partition Table: msdos", then my hypothesis is correct. In this case, IMHO your best bet is to convert the disk from MBR to GPT format. You can use gdisk to do this, as described here. (You'll probably have to install the gdisk package, which I believe is part of Mint.) The conversion process itself is extremely simple -- just launch gdisk, verify that you're working on the right disk by reviewing your partitions with the "p" command, and save the partition table with "w". The complication is that you'll then need to re-install your boot loader. Assuming you're using GRUB, this works best if you place a BIOS Boot Partition on your disk, and it may need to go before the 2TiB mark, so you may need to shrink one of your existing partitions to make room for it. The BIOS Boot Partition can be quite small -- often under 1MiB, although I've seen claims that some versions require up to 2MiB. Note that's MiB, not GiB. It's identified by a type code of EF02 in gdisk or by having a "bios_grub" flag set in parted or GParted, and it contains no filesystem.

All of this is best done from an emergency recovery disk -- either Mint in its "try it before installing" mode or something like System Rescue CD or Parted Magic. You could do the partition table conversion from your regular installation, but resizing your partitions would require unmounting them, and it just gets hairier from then on.

One more point: If your motherboard is new enough, it may support UEFI booting, and converting from MBR to GPT might make the motherboard favor that boot method. This is unlikely, but possible. If you run into this problem, you may need to create an EFI System Partition rather than a BIOS Boot Partition and install an EFI-mode boot loader rather than a BIOS boot loader. There are also a small number of BIOSes that have bugs that prevent booting from GPT disks. Many such BIOSes are actually early UEFI implementations, though, so you may be able to switch to EFI boot mode with them. Most other such problems can be worked around, as described on the page to which I've just linked.

You are right, it was an MBR partition, and what you said makes sense and explains my confusion about why it went over the 2TiB limit. I installed gdisk from the repo, ran it, and wrote the change. I made a 2MiB partition before my 15GiB root partition using gparted, set the flag to bios_grub with no filesystem. I ran boot repair CD to reload GRUB, it is constantly searching for filesystem. The motherboard is a Gigabyte GA-970-UD3 Rev 1.2 http://www.gigabyte.com/products/product-page.aspx?pid=4417#ov EFI boot is set to auto.

I really appreciate the answer. As a thank you, I can send you something from Jungle Jim's if you like. You gotta miss it.

skunkarific wrote:I made a 2MiB partition before my 15GiB root partition using gparted, set the flag to bios_grub with no filesystem. I ran boot repair CD to reload GRUB, it is constantly searching for filesystem.

I'm afraid I don't quite understand what you mean by this. Are you saying that you're having problems re-installing GRUB, that GRUB isn't working once installed, or something else? If you're having problems, posting details is in order.

It looks like the motherboard supports Gigabyte's ghastly Hybrid EFI implementation. If you're having problems, it's conceivable that this is a cause. Simultaneously, although Hybrid EFI is a very poor EFI implementation, it does provide you with additional boot options, and in some cases, you might want to use this feature. I might be better able to advise you if you post more details. (Be aware that I'm the author of the Web page on Hybrid EFI to which I linked, so I have direct personal experience with this firmware. I also maintain the rEFInd boot manager, so I understand this class of software quite well.)

Honored to have you helping. With no guarantee of resolution, probable hardware issues (I have another post about not being able to load Mint on this board easily), I chose instead to make a 3TB RAID 1 array, and leave the OS on the 2TB disk.

I took the time to find and read your website. I'm impressed. What motherboards have you found work best with EFI?

skunkarific wrote:I took the time to find and read your website. I'm impressed. What motherboards have you found work best with EFI?

I only have experience with four actual EFI-based products (counting my Mac Mini), which I would rate as follows, from best to worst:

ASUS P8H77-I -- This has a new UEFI 2.3.1 implementation that supports a flashy GUI configuration tool and Secure Boot. Although it's got some quirks and weirdness (like an inability to disable CSM support and very bad names for some firmware options), it handles the basics well. Its Secure Boot capability is useful to me personally, since it's enabled me to add shim/Secure Boot support to rEFInd, but for a Linux computer, Secure Boot is more of a hassle than a benefit right now, so I'd suggest other Linux users leave it disabled. This may change in time or be more important on a dual-boot configuration.

First-generation Intel-based Mac Mini (32-bit) -- This one boots reliably in EFI mode, but for some reason I've been unable to get a Linux kernel with EFI stub support to boot from a FAT partition; the kernel just can't seem to find its initrd file when booted in this way. Also, AFAIK no Linux distribution ships with install-time support for a 32-bit EFI-mode installation, so it's necessary to install in BIOS mode and then switch over. Note that the quality of EFI-mode booting on Macs varies greatly from one model to another; many models have problems activating video or other hardware in EFI mode. Like all Macs, this one officially has an EFI 1.x implementation, not a UEFI 2.x implementation.

Intel DG43NB -- This is a relatively early (2008) UEFI board with an EFI 2.0 firmware. Intel doesn't emphasize EFI-mode booting in its documentation, but it does work. The firmware's EFI user interface options are limited, though, and for some reason the BootOrder option (set via Linux's efibootmgr, among other tools) is ignored -- the system boots whatever boot loader you added first. This makes switching the default boot loader awkward at best.

Gigabyte GA-78LMT-S2P -- I bought this board about a year ago. It's got a very primitive UEFI 2.1 implementation that runs atop a conventional BIOS. (This is what Gigabyte calls a "Hybrid EFI.") It's got a lot of bugs -- in such quantity and causing so much frustration to me that I wrote a Web page detailing them. Don't let the numbering confuse you -- this board is #4 in my list, but the gap between it and #3 is far greater than the gap between #3 and #1. Unless you have a compelling reason to boot such a board in EFI mode, it's better to treat them as having conventional BIOS firmware.

I also have experience with the EFI support in VirtualBox and DUET (an add-on that lets you launch a UEFI implementation on some BIOS-based computers). Both of these are rather primitive. DUET is intended as a developer's tool, but it can be handy if you want to learn about EFI or if you're desperate to do something like install Windows on an over-2TiB disk. VirtualBox's EFI support works, but it's got some annoying quirks, like a keyboard interface that drops characters randomly, making typing in a shell awkward. (This problem doesn't affect Linux, just EFI programs like boot loaders and the EFI shell.)

I was all jazzed about the Asus board, until I saw Mini ITX....grrrrrI avoid ANYTHING Apple makes. Their Ibull**** has done more to hurt Linux sales than everything else combined.The older Intel board wouldn't be currently available, and like you, I agree Intel's ways are strange and confusing.GA-78LMT-S2P. I've sold probably a thousand or more. Love the board. That's what I replaced in my system, I needed 32GB RAM for all the virtuals I run. They just came out with a newer one that will support that much memory. I think I'll try that out. Read your page about Gigabyte's hybrid EFI. I've never had a 78LMT board reset anything...weird.

skunkarific wrote:I was all jazzed about the Asus board, until I saw Mini ITX....grrrrr

I'm pretty sure ASUS makes boards with similar specs in bigger sizes (and with more slots to go with it). A Google on "ASUS P8H77" (without the "-I") turned up hits on P8H77-M and P8H77-V, with photos that suggest those are Micro-ATX and full-ATX boards, respectively. ASUS also makes numerous other models, of course, and these days most or all of them have similar UEFI firmware.

GA-78LMT-S2P. I've sold probably a thousand or more. Love the board. That's what I replaced in my system, I needed 32GB RAM for all the virtuals I run. They just came out with a newer one that will support that much memory. I think I'll try that out. Read your page about Gigabyte's hybrid EFI. I've never had a 78LMT board reset anything...weird.

I have few complaints about the hardware (the main one being that it's skimpy on the slots for its size). It's the EFI implementation that's bad. Apparently some newer Gigabyte models have an updated EFI implementation, but I don't know the details, and I don't have one for study. If you like Gigabyte and want EFI, I suggest avoiding the Hybrid EFI and going for whatever they're offering that's more recent.