How do I convert the default MBR partitioning scheme of my CentOS EC2 instance to GPT so I can bypass the 2 TiB limit for MBR partitions on my EBS volume?

10 minute read
0

My Amazon Elastic Compute Cloud (Amazon EC2) instance runs CentOS 7 from the AWS Marketplace by centos.org. I want to convert the default MBR partitioning scheme on my Amazon Elastic Block Store (Amazon EBS) volume to the GPT partitioning scheme to bypass the 2 TiB limit for MBR partitions.

Resolution

Warning: Before you stop and start your instance, be sure that you understand the following:

  • Instance store data is lost when you stop and start an instance. If your instance is instance store-backed or has instance store volumes that contain data, the data is lost when you stop the instance. For more information, see Determine the root device type of your instance.
  • If your instance is part of an Amazon EC2 Auto Scaling group, the instance might terminate when you stop the instance. If you launch the instance with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk, then your instance might be part of an AWS Auto Scaling group. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, then temporarily remove the instance from the Auto Scaling group before you start the resolution steps.
  • When you stop and start the instance, the public IP address of your instance changes. It's a best practice to use an Elastic IP address instead of a public IP address. If you use Route 53, you might need to update the Route 53 DNS records when the public IP changes.

Note: It's a best practice to create a backup of your EBS volume before you begin any resolution steps.

To convert the default MBR partitioning scheme of a CentOS EC2 instance to GPT, follow these steps:

  1. Open the Amazon EC2 console.
  2. Launch an instance from an AWS Marketplace Amazon Machine Image (AMI) that runs CentOS 7.
  3. In the same Availability Zone as the first instance, launch a second instance from the same CentOS AMI that has a 3TiB root volume.
    Note: If you already have a CentOS 7 instance, you don't need to launch a new CentOS 7 instance. For CentOS 7, modify the root volume to extend its size to over 2 TiB.
  4. Stop the instance with the 3 TiB root volume, and then stop the instance that you created in step 2.
    Note: Because CentOS 7 is from an AWS Marketplace AMI, you must stop your instance before you attach a volume with AWS Marketplace codes. If you don't stop the instance, the following error occurs: "Error attaching volume: Cannot attach volume 'vol-#################' with Marketplace codes as the instance 'i-################' is not in the 'stopped' state."

Detach the root volume (/dev/xvda or /dev/sda1) from the stopped instance. Then, attach it to the instance that you created in step 2 as /dev/sdf.
Note: If you use the Xen platform instance type, then the device name appears as /dev/sdf or /dev/sda. If you use the Nitro platform instance type, then the device name appears as /dev/nvme0n1 or /dev/nvme1n1.

  1. Start the instance that you launched in step 2, and then connect to it with SSH.

  2. To view the root partition of /dev/sdf, use the lsblk command. The root partition of /dev/sdf is only 2 TiB, as the following example shows:

    # lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    (snip)
    xvdf    202:80    0   3T  0 disk
    └─xvdf1 202:81    0   2T  0 part
    (snip)

    Note: /dev/xvdf1 might mount as the root file system "/". If this occurs, stop and start the instance a few times until /dev/xvda1 mounts as the root file system.

    # lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0   8G  0 disk
    └─xvda1 202:1    0   8G  0 part /
    xvdf    202:80   0   3T  0 disk
    └─xvdf1 202:81   0   2T  0 part 
  3. To convert the partition table from MBR to GPT, use the gdisk tool.
    Note: If the gdisk tool isn't already installed, you can install it with the command sudo yum install gdisk -y.

    # sudo gdisk /dev/xvdf
    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!
  4. To create a GPT partition, enter the following commands at the prompts. Type enter at the Last sector prompt to use the default sector number 2047.

    Command (? for help): n
    Partition number (2-128, default 2): 128
    First sector (34-6291455966, default = 4294967296) or {+-}size{KMGTP}: 34
    Last sector (34-2047, default = 2047) or {+-}size{KMGTP}:
    Current type is 'Linux filesystem'
    Hex code or GUID (L to show codes, Enter = 8300): ef02
    Changed type of partition to 'BIOS boot partition'

    Note: In the previous example, ef02 is the BIOS boot partition number.

  5. To delete the root partition, enter the following commands at the prompts:

    Command (? for help): d
    Partition number (1-128): 1
  6. To recreate the root partition to 3 TB, enter the following commands at the prompts. In the First sector, Last sector, and Hex code or GUID prompts, type enter to use the default settings.

    Command (? for help): n
    Partition number (1-128, default 1): 1
    First sector (2048-6291455966, default = 2048) or {+-}size{KMGTP}:
    Last sector (2048-6291455966, default = 6291455966) or {+-}size{KMGTP}:
    Current type is 'Linux filesystem'
    Hex code or GUID (L to show codes, Enter = 8300):
    Changed type of partition to 'Linux filesystem'
  7. To save the GPT partition table, enter the following commands at the prompts:

    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.

    To view the new partition information, run the command, and then view the results:

    $ sudo gdisk -l /dev/xvdf
    GPT fdisk (gdisk) version 0.8.10
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/xvda: 6291456000 sectors, 2.9 TiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 35D6B819-1C79-4EC0-920F-4D1191609505
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 6291455966
    Partitions will be aligned on 8-sector boundaries
    Total free space is 0 sectors (0 bytes)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1            2048      6291455966   2.9 TiB     8300  Linux filesystem
     128              34            2047   1007.0 KiB  EF02  BIOS boot partition
  8. To check that the file system of device /dev/xvdf1 is correct, use the file system check and repair tool:

    # sudo xfs_repair /dev/xvdf1
    Phase 1 - find and verify superblock...
            - reporting progress in intervals of 15 minutes
    Phase 2 - using internal log
            - zero log...
            - scan filesystem freespace and inode maps...
            - 05:27:07: scanning filesystem freespace - 1025 of 1025 allocation groups done
            - found root inode chunk
    Phase 3 - for each AG...
            - scan and clear agi unlinked lists...
            - 05:27:07: scanning agi unlinked lists - 1025 of 1025 allocation groups done
            - process known inodes and perform inode discovery...
            - agno = 960
            - agno = 0
            - agno = 240
            - agno = 480
    
    (snip)
            - agno = 238
            - agno = 239
            - 05:27:08: process known inodes and inode discovery - 25856 of 25856 inodes done
            - process newly discovered inodes...
            - 05:27:08: process newly discovered inodes - 1025 of 1025 allocation groups done
    Phase 4 - check for duplicate blocks...
            - setting up duplicate extent list...
            - 05:27:08: setting up duplicate extent list - 1025 of 1025 allocation groups done
            - check for inodes claiming duplicate blocks...
            - agno = 0
            - agno = 1
            - agno = 2
            - agno = 3
            - agno = 4
    
    (snip)
            - agno = 1021
            - agno = 1022
            - agno = 1023
            - agno = 1024
            - 05:27:08: check for inodes claiming duplicate blocks - 25856 of 25856 inodes done
    Phase 5 - rebuild AG headers and trees...
            - 05:27:08: rebuild AG headers and trees - 1025 of 1025 allocation groups done
            - reset superblock...
    Phase 6 - check inode connectivity...
            - resetting contents of realtime bitmap and summary inodes
            - traversing filesystem ...
            - traversal finished ...
            - moving disconnected inodes to lost+found ...
    Phase 7 - verify and correct link counts...
            - 05:27:08: verify and correct link counts - 1025 of 1025 allocation groups done
    done
    

    CentOS 6:

    # sudo e2fsck -f /dev/xvdf1
    e2fsck 1.41.12 (17-May-2010)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    /dev/xvdf1: 18734/524288 files (0.2% non-contiguous), 284948/2096896 blocks
  9. To resize the file system to extend it to 3 TB, run the xfs_growfs or resize2fs command.
    Note: It might take a few minutes to resize the file system.

    CentOS 7:

    # sudo mount -o nouuid /dev/xvdf1 /mnt
    
    # sudo xfs_growfs /dev/xvdf1
    meta-data=/dev/xvdf1             isize=512    agcount=1025, agsize=524224 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=0 spinodes=0
    data     =                       bsize=4096   blocks=536870656, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
    log      =internal               bsize=4096   blocks=2560, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    data blocks changed from 536870656 to 786431739

    CentOS 6:

    # sudo resize2fs /dev/xvdf1
    resize2fs 1.41.12 (17-May-2010)
    Resizing the filesystem on /dev/xvdf1 to 786431739 (4k) blocks.
    
    The filesystem on /dev/xvdf1 is now 786431739 blocks long.
    
  10. Install Grub on the device /dev/xvdf1 and configure it with the following commands.
    Note: Grub installation isn't required for S 6. If you use CentOS 6, skip to step 16.

    CentOS 7:

    sudo mount --bind /proc /mnt/proc
    sudo mount --bind /sys /mnt/sys
    sudo mount --bind /dev /mnt/dev
    sudo chroot /mnt /bin/bash
    grub2-install /dev/xvdf
    exit
    sudo umount -l /mnt/dev
    sudo umount -l /mnt/sys
    sudo umount -l /mnt/proc
    sudo umount -l /mnt
  11. Stop the instance.

  12. Detach the volume /dev/xvdf from the stopped instance.

  13. Attach the volume /dev/xvdf back to its original instance as /dev/sda1.

  14. Start the original instance, and then connect to it with SSH.

  15. To verify that the root volume on your original instance now has 3 TiB of space, run the lsblk command.

    $ lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0   3T  0 disk
    └─xvda1 202:1    0   3T  0 part /

Related information

How do I convert my EC2 Ubuntu instance's default MBR partitioning scheme to GPT to bypass the 2-TiB limit for MBR partitions on my EBS volume?

AWS OFFICIAL
AWS OFFICIALUpdated 2 days ago