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

amazon ec2amazon-web-servicesgptgrub2mbr

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:
    enter image description here

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.

Best Answer

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.

Related Topic