Transforming a disk from MBR to GPT

Question

I have a disk with classic MBR and want to transform it to use GPT without data loss. I have seen several more or less useful tutorials, but most of them are dealing with the specific problems related to GRUB, the operating systems and multiple partitions on a disk. In my case, the situation is much simpler - I have a simple disk used to store data on a single partition. I discovered that simply running gdisk and pressing w writes GPT to the disk and I can mount and use it without issues afterwards.

I am worried about data corruption though, gdisk warns me that the operation I'm about to perform is potentially destructive, and I've seen diagrams on which GPT occupies some space which is normally used by the first partition. So my questions are:

Is this a good way to transform MBR to GPT?

Can GPT overwrite some data which was originally on the primary partition, thus corrupting my files or the filesystem?

Solution 1

I created an MBR disk with one partition, filled every single byte on that partition with data, created a SHA1 checksum of the whole partition, converted it to GPT as described in the question, created yet another checksum and compared it with the original. They were the same. So my conclusion is this: You can safely convert a disk to GPT without corrupting the data.

Warning: This does not mean the procedure is safe. It might corrupt your partitions. Always make a backup before converting using this approach.

Solution 2

I successfully achieved converting MBR to GPT, but used two extra (new) disks for safety reasons. Note that I'm using Debian in combination with the GRUB bootloader.

With my setup, which simply has a Linux partition and a swap partition, the procedure is roughly as following.

First, make a full backup:

• use the first extra disk to make a full backup of the old disk
• disconnect (!) the original drive and put it somewhere safe (this guarantees we're not writing it by accident)
• connect the backup drive such that you can boot from it (e.g. first SATA connection on mother board)
• also connect the second extra disk
• boot from your backup disk

If you can boot and everything works normally, this also proves your backup is sound. Now let's really begin:

• partition the still empty second disk using gdisk in the new MPT format
• deliberately use the same partition sizes as the old disk so we can easily migrate
• use the code 8300 for the linux partition and 8200 for the linux swap partition.
• also create an extra 2 MiB partition using the ef02 code, remember the partition number we will need it later.

Note: This 2 MiB partition is for booting GRUB and does not have to be at the start of the disk per se.

• use dd to copy the data from the boot disk Linux partition to the new
• activate the newly created swap partition (use the mkswap command)

At this stage, the system files and your data have been copied to the new disk. Only thing that remains is to make things bootable.

• Run the following command: parted /dev/sdXXX set YYY bios_grub on where XXX is the device corresponding to the 2 MiB partition we have created and YYY the partition number I asked you to remember.

• Run grub-install /dev/sdZ where sdZ is the disk you want to make bootable.

• Disconnect the backup disk

• Wire the GPT disk so you can boot from it
• Test (boot into your new GPT enabled disk)

Good luck!

Comments

[Admin]

We all want everything to happen without data loss. I'm not sure if a tool that says, "Don't worry, everything will be fine!" is really going to be better, if that's what you are asking. Back up your tish and keep it backed up. Also: run fsck (or whatever is appropriate to the fs type) on the partitions afterward; this should give you a good idea of whether anything was corrupted or not.

[Admin]

Sure, I'm backing up most of my data all the time, but in this case, we're talking about two terabytes of data. I don't have enough space for that. In fact, I'm transforming the disk to GPT so that I can create a partition larger than that.

[Erathiel]

Actually this allows us to conclude that in your case it was safe to do so but we should not generalise, especially since your case was rather simple with a single-partition setup. Good to know you were successful, though.

[JohnEye]

@Erathiel: My memory of the whole problem is now a bit dated, but I think that when I was researching it, I had some good reasons to belive that if this simple scenario didn't fail, more complex setups would be fine as well. But I'll add some warning, just in case.

[JohnEye]

I really appreciate how failsafe your procedure is.

[Erathiel]

Well, sorry, I didn't notice your answer was already a few months old when I posted my comment. Still, the comment holds true, IMO. If you test a method in a fairly complex scenario and it works you may rather safely assume it should also work in a simpler case. Drawing conclusions from a reverse case is risky. Plus, it's always good to remind people of making backups before such operations ;)