Remove GPT - Default back to MBR

Question

I keep receiving this error:

Warning!! Unsupported GPT (GUID Partition Table) detected. Use GNU Parted

I want to go back to the normal MBR. I found some advice here and did:

parted /dev/sda
mklabel msdos
quit

But when I get to the mklabel option it spits out a warning that I will lose all data on /dev/sda. Is there a way to get the normal MBR back without formatting the disk?

Answer 1

That link you posted looks like a very ugly hack type solution.

However, according to the man page, gdisk, which is used to convert MBR -> GPT, also has an option in the "recovery & transformation" menu (press r to get that) to convert GPT -> MBR; the g key will:

Convert GPT into MBR and exit. This option converts as many partitions as possible into MBR form, destroys the GPT data structures, saves the new MBR, and exits. Use this option if you've tried GPT and find that MBR works better for you. Note that this function generates up to four primary MBR partitions or three primary partitions and as many logical partitions as can be generated. Each logical partition requires at least one unallocated block immediately before its first block.

I'd try that first.

Answer 2

Most of the previous respondents are correct when they say that you can usually do what you need with a GPT partition table layout, but since there are valid reasons for wanting to use MBR, I think I will just answer your question instead of assuming you are wrong for asking.

To get rid of the GPT, you need to remember that with this format, there is a partition table written to the end of the drive, where it will remain if you just try to delete it with fdisk or a non-GPT aware file system tool. What you did with parted did not address this partition table.

To erase GPT, you need to use something like gdisk. Enter gdisk as root at the prompt, and then tell gdisk what device you want to look at (i.e. /dev/sd??). Use gdisk to write a protective MBR to the disk just to make sure you have access to some MBR data structure. Then you can navigate to the expert options section (press ? at the different program prompts to see the options available to you at different times) and find the option that says "Zap (destroy) the GPT data structures and exit." The program will prompt for confirmation, then ask you if you want to preserve the MBR structure. Do preserve this.

After that, it should be as simple as rebooting your computer (because the kernel will still be using the old partition table and it needs a restart to update), and then firing up fdisk and deleting the remnant of the GPT partition. You will still see the same warning about using GNU Parted that you saw before, but you can ignore it this time, as it will go away when you delete the partition.

This will give you an MBR partition table system on a blank drive onto which you can reinstall an OS. If you are attempting to do this with existing partitions, it is quite a bit more complicated and in some cases not even possible, so I would recommend that you simply back up your data and do it this way.

Answer 3

Use gdisk /dev/sda

Note: /dev/sda is in the case of the person who asked this question but change it to your drive name.

Once you are inside with gdisk use:

x   extra functionality (experts only)

then when you type p to see all the options, you will see this:

Expert command (? for help): ?
a   set attributes
c   change partition GUID
d   display the sector alignment value
e   relocate backup data structures to the end of the disk
g   change disk GUID
h   recompute CHS values in protective/hybrid MBR
i   show detailed information on a partition
l   set the sector alignment value
m   return to main menu
n   create a new protective MBR
o   print protective MBR data
p   print the partition table
q   quit without saving changes
r   recovery and transformation options (experts only)
s   resize partition table
t   transpose two partition table entries
u   Replicate partition table on new device
v   verify disk
w   write table to disk and exit
z   zap (destroy) GPT data structures and exit
?   print this menu

Use z

Expert command (? for help): z
About to wipe out GPT on /dev/xvdf. Proceed? (Y/N): Y
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): Y

Answer 4

GParted did the job for me (tested on Kali Linux USB Live v2.1) just by doing:

Device --> Create Partition Tablet --> Type MSDOS

Delete all partitions first.

Answer 5

This should work for most cases. You know you cannot use a MBR when you have partitions larger than 2TB, or for more than 15 partitions.

• Use parted to check partition's sizes (i.e. are all smaller than 2TB?), parted /dev/sdX p
• In case there are larger partitions, shrink the filesystem in question and everything else that needs to be done. (More on this at the end of this posting.)
• Dump all the exact partition sizes, parted /dev/sdX u B p (show sizes in bytes), so you know how you could eventually recreate the partition layout. Use your phone to make a photo from both parted outputs.
• Remember you can only have four primary partitions with a MBR due to its internal structure. So if you have more partitions, you need free space somewhere on your disk (ofc you need to know where this could be!), to create a logical partition where a VBR can be put onto so you can 'allocate' the other 4th/5th/6th partition that previously existed.
• Use gdisk to zap the GPT.
• Create a new MBR.
• Recreate your partitions, the 1st/2nd/3rd as primary partitions, then on some free space (WHERE NO DATA WAS LOCATED PRIOR!!!) create a logical partition, then create the others.
• Save, quit.
• Pray.
• Reboot.

You should use a livedisk like grml for all this. In case you did something wrong, reboot and retry.

As long as you do not write any data onto the disk, nothing is lost. Remember you still have all your partition layout on your phone, so you can recreate the original GPT if really need be.

In case your really fuck something up and did not take photos, try testdisk for discerning the partition boundaries. But don't bet any money on it as soon as your layout was anything extraordinary.

---

On the resizing stuff for making partitions smaller, birds eye perspective:

• First you always have to shrink the filesystem. Easy for ext4 (resize2fs -M dev/sdX), but impossible for XFS as it cannot be shrunk. Know what you are using and google before attempting such stunts.
• If you have LVM, shrink the logical volume next. (lvreduce -L 20G /dev/mapper/<VG>-<LV>)
• Next LVM step is downsizing the physical volume. pvresize --setphysicalvolumesize 25G /dev/sdX is the way to go.
• Afterwards use the partitioning tool of choice, delete the partition where your lvm is put on, and recreate it smaller.

Sizes for all mentioned elements mentioned here are like: Filesystem < LV < PV < partition, if this is not the case after the next reboot you will see you have to do a FS check. Don't do it, just reboot into the livedisk again, and make your adjustments. If you fix things there, your system will boot again, I promise.

To be able to do all this, in case you have PARTITION + LUKS + LVM + FILESYSTEM, here are some hints on how to do this from the shell:

• df -h is your friend for showing the filesystem size when you mounted the partition
• lsblk and lsblk -f are your friends for showing partitions
• If you use LUKS, open the crypto container via cryptsetup open /dev/sdX asdf, enter your password and it should become available unter /dev/mapper/asdf. Cryptocontainers do not need to be resized. (Skip this if you don't have an encrypted partition, of course.)
• vgchange -aay to activate all logical volumes so you can work with them.
• mkdir asdf; mount /dev/mapper<VG>-<LV> asdf and then df -h to check the size of your filesystem prior to resizing.
• umount asdf so it is unmounted again.
• resize2fs -M /dev/mapper/<VG>-<LV>.
• mount /dev/mapper/<VG>-<LV> asdf; df -h to check how big your filesystem still is.
• Make the LV 1GB bigger than the file system. Chances are, this will not be sufficient. Make it even bigger than that if you can affort it, else linux will tell you after the reboot that it won't work. DONT do the FS check when prompted, reboot into the livedisk and start again, no data is lost if that was the case.
• Make the PV 1GB bigger than the LV.
• Make the partition 1GB bigger then the PV. 100M should easily be sufficient, too, as LVM creates extents in size of 4M (that's somewhat like blocks on the harddisk directly, but for LVM), and you only want it to not omit the last extent by making the partition too small. But as I said, should. Don't calculate everything, just adjust things and fix them if they break. It's linux after all, it let's you do this.

Make things bigger than they need to be, so you don't have to reboot as often.

To easily discern what is what with LVM, always use your hostname as name for the VG and the mountpoint (root, swap, var, ...) for the LV when creating your LVM setup, if you didn't already do it. This is general hint, not something you are required to do for anything of the above steps.