1

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.

  • 2
    If you really need this, it's best to start with a new instance. Though I'm not even sure you can do this at all on EC2, and it probably doesn't make any sense to have a large root volume anyway. – Michael Hampton Nov 15 '18 at 0:12
  • What do you mean by start with a new instance? Would you create a new instance greater than 2TB and then dd the contents from the old drive to the new drive? That way avoiding the GPT/boot stuff manually? Your comment did give me another idea, I may just create a new data volume with a snapshot of the root volume, adjust things to point to the new data drive and expand that as needed. Eventually shrink the root volume since it won't be holding my data. – Justin Heath Nov 15 '18 at 15:43
  • I wouldn't run an instance with a 2TB root volume, ever, for any "reason". – Michael Hampton Nov 15 '18 at 16:10
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.