What are the steps to convert an EBS boot volume from MBR to GPT without data loss? (Using Ubuntu)

Question

I would like to extend one of my Ubuntu servers main/boot drive beyond 2TB. I know that I need to convert the drive to use GPT, and I'm confident that I can extend the size as needed once I'm able to convert to GPT successfully.

I set up a test server to test out the process before attempting anything on an actual production server, and here's what I've tried so far.

1. I detached the EBS volume from my server (was mounted at /dev/xvda1).
2. I attached the volume to another running server, at /dev/sdf (which shows up as /dev/xvdf on the running server.

3. sudo gdisk /dev/xvdf followed by p and get the following output:

   GPT fdisk (gdisk) version 1.0.1
   
   Partition table scan:
     MBR: MBR only
     BSD: not present
     APM: not present
     GPT: not present
   
   
   ***************************************************************
   Found invalid GPT and valid MBR; converting MBR to GPT format
   in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
   typing 'q' if you don't want to convert your MBR partitions
   to GPT format!
   ***************************************************************
   
   Command (? for help): p
   Disk /dev/xvdf: 104857600 sectors, 50.0 GiB
   Logical sector size: 512 bytes
   Disk identifier (GUID): 4FD95BA1-74A4-4241-98E5-CA0276008D62
   Partition table holds up to 128 entries
   First usable sector is 34, last usable sector is 104857566
   Partitions will be aligned on 2048-sector boundaries
   Total free space is 2014 sectors (1007.0 KiB)
   
   Number  Start (sector)    End (sector)  Size       Code  Name
      1            2048       104857566   50.0 GiB    8300  Linux         filesystem
   

4. I attempt to just write the table as-is:

   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
   OK; writing new GUID partition table (GPT) to /dev/xvdf.
   The operation has completed successfully.
   

5. At this point, I detach the volume and reattach to the original EC2 instance and attempt to reboot. The server never becomes reachable.

6. I do a little more research and believe my issue is that I need to create a bios boot partition and install grub. Reattaching my volume to another instance, I created a new partition, so now I have the following:

   Number  Start (sector)    End (sector)  Size       Code  Name
      1            2048       104857566   50.0 GiB    8300  Linux filesystem
      2              34            2047   1007.0 KiB  EF02  BIOS boot partition
   

7. Then I needed to install GRUB, so I did the following: $ sudo grub-install /dev/xvdf Installing for i386-pc platform. Installation finished. No error reported.

8. Detached/Reattached and no dice again. At this point I learned that I could view a screenshot from the EC2 dashboard and captured the following:

At this point I'm just throwing things at the wall to see if they stick. I have no idea what I am doing, but feel I'm missing something basic.

As I said, if I can add GPT to the volume and successfully boot it, I'm not worried about the steps needed to actually resize the volume.

Answer 1

Yes you can change the partition type.

Prefer to take databackup of snapshot of the disk first for the safer side.

Please check the link.

Answer 2

A safe way to adjust storage and still have a bootable system is to not to change the partition of the root volume.

Attach new data disks. Create LVM volumes on them, don't bother partitioning: vgcreate datavg /dev/sdb. Restore backed up files, just the data not the OS, onto the new storage.

The new instance idea is if you really want to resize the root volume. Provisioning a 2 TB root volume would require GPT from the start. Then restore your data and have a working system without the partitioning dance.