Grub won't boot after converting MBR partition table to GPT

Question

I have a problem on booting my Ubuntu 16.04.2 LTS after converting my hard drive from MBR to GPT. As I found it on other websites, I used gdisk to convert the hard drive from MBR to GPT. After doing so and restarted my PC, it turned out that the GRUB OS Menu do not display on boot, instead, the screen just showed me a black screen with a blinking cursor. When I tried to convert the GPT back to MBR partition table, the command seemed to be successful but the GRUB is still not working

Additional Info: I am dual-booting Ubuntu 16.04 and Windows 10

Command used to convert MBT to GPT:

sudo gdisk /dev/sda Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!

Do you want to proceed? (Y/N): Y

Anyone who knows how to fix the problem? Am I doing something wrong?

Solution 1

Short answer:

grub i386-pc needs a "BIOS boot partition" (i.e. type ef02 in gdisk). So you need to create one after the conversion, before running grub-install again.

Explanation:

It's only natural that grub will not work when youn convert your MBR/msdos partition table to GUID partition table.

The reason is, grub makes use of the "post-MBR gap", that is, the gap between the MBR and the first partition, for embedding a portion of its boot code (a.k.a. core.img). When you convert the partition table to GPT, part of the gap is overwritten with the main GPT, for it lies on LBA 1-33 (where the MBR lies on LBA 0).

Moreover, BIOS grub (a.k.a. grub i386-pc) on GPT no longer make use of the post-MBR, or post-GPT gap for core.img embedding. Instead it needs a "BIOS boot partition" (i.e. type ef02 in gdisk). So you need to create one after the conversion, before running grub-install again.

Also, note that a backup GPT lies at the last 33 logical blocks of the disk. If the last/only partition extended till the last block of the disk, you would need to shrink the filesystem on it to make sure that the filesystem no longer covered the last 33 blocks of the partition/disk, so that the blocks could be safely overwritten with the backup GPT. If you didn't do that before the conversion, there could be some damages done to the filesystem.

Solution 2

Tom Yan's answer is a good one, and following that advice will likely lead to a solution; however, I want to step back a bit and ask another few, which may lead to equally good (and maybe better) alternatives:

• Why do the MBR-to-GPT conversion? A conversion from MBR to GPT is critical in some rare circumstances, helpful in a few, and a pointless risk in most situations. If there was a real reason for doing the conversion (say, if the disk was over 2 TiB in size and therefore under-utilized by MBR), then keeping it in GPT form is important. If not, then converting it back to MBR form may be a reasonable option -- although doing so will not recover the BIOS-mode boot loader; that will still need to be re-installed. OTOH, the backward conversion will offer few advantages -- mainly just the fact that you won't need to create a BIOS Boot Partition. A small number of computers have trouble booting in BIOS mode from GPT disks, too. If you want to do a GPT-to-MBR conversion, see this section of the GPT fdisk documentation.
• Does the computer support EFI-mode booting? If the computer (or motherboard) is a model introduced after late 2011, chances are it's EFI-based. If so, converting to boot in EFI mode, rather than in BIOS mode, makes sense. Doing this requires installing an EFI boot loader. I describe the options in this page. The easiest to install are likely to be GRUB 2 (which you can install with Boot Repair) and my own rEFInd (which you can install by using the rEFInd USB flash drive or CD-R to boot and then installing the rEFInd PPA or Debian package in Ubuntu). Note that a conversion to EFI-mode booting will require creating an EFI System Partition (ESP), which is bigger than a BIOS Boot Partition (I recommend 550 MiB for an ESP).
• What OS(es) other than Ubuntu are installed on the computer? If the computer boots nothing but Ubuntu, you need to be concerned only with getting one OS booting again. If you're booting something else, though, you must consider that OS's capabilities and boot loader. Windows, in particular, can be very limiting. In Windows, the boot mode and partition table type are tied, so if you keep the GPT configuration, you must convert to booting in EFI mode. This is likely to be more work than switching back to an MBR. This new Microsoft tool can do the conversion, but it's designed with an MBR partition table as a starting point and I have no idea how it would react to a dual boot or a system with the partition table already converted to GPT. There used to be sites with step-by-step instructions for manual conversions, but the sites I'm aware of with this information have all disappeared, so I have no pointers any more.

EFI-mode booting has some advantages over BIOS-mode booting, including slightly faster boot times (usually), in-OS control of boot order, access to some boot and firmware information from the OS, better security (in the form of Secure Boot, if it's supported on your hardware), more flexible boot loader management, and easier boot loader management (once you understand how; the learning curve is admittedly a bit steep). OTOH, switching to EFI-mode booting, even if it's possible, can easily lead to new problems, particularly if you don't know what you're doing.Thus, installing a BIOS-mode boot loader, with or without a reversal of the MBR-to-GPT conversion, is likely to be the safer approach in the short term. If the system multi-booted with another OS, the situation becomes much more complex, and it's almost certain to be easiest to go back to MBR. Without knowing the answers to the three bullet-point questions, I can't provide firm advice on whether to try such a conversion.

Comments

[ravery]

you answered your own question "Warning this will overwrite existing partitions"

[Tom Yan]

Not sure if that's the actual problem. He should be able to see if the partitions are gone with fdisk -l or gdisk -l.

[Chamber]

@TomYan the partitions are not gone when I typed fdisk -l but I think it's the Grub that has the problem

[Rod Smith]

As the author of GPT fdisk (gdisk), I can confirm that the issue is almost certainly exactly as Tom Yan has described. One of GPT fdisk's features is lossless conversion of MBR to GPT partitions -- but note that "lossless" applies to partitions and the data they contain, not to boot loader data, which in the case of BIOS-booted MBR disks often exists exactly where GPT data structures must reside. Thus, the MBR-to-GPT conversion wiped out part of GRUB, and converting back would not help.

[Tom Yan]

@CharlesGreen the third paragraph provides the solution, which is creating a BIOS boot partition and re-run grub-install. I do admit that I didn't provide concrete steps for doing it. The reason for that is no detail partition layout or so is provided in the OP. Detailed steps could vary anyway. It could be possible to create one by overriding partition alignment setting in gdisk and make use of the post-GPT gap. Less ugly approach might be shrinking one of the partitions and make use of the space reclaimed. I don't think it's appropriate to provide a "guide"/"tutorial" for this.

[Elder Geek]

@CharlesGreen I believe the intended answer is in the paragraph beginning with the word "Moreover"