How do I convert the default MBR partitioning scheme of my CentOS EC2 instance to GPT so that I can bypass the 2-TiB limit for MBR partitions on my EBS volume?
My Amazon Elastic Compute Cloud (Amazon EC2) instance runs CentOS 7 from the AWS Marketplace by centos.org. There's a 2-TiB limit for MBR partitions. To bypass this limit, I want to convert the partitioning scheme on my Amazon Elastic Block Store (Amazon EBS) volume to a GPT partitioning scheme.
Resolution
Important: Before you stop and start your instance, make sure that you review 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 Root volumes for your Amazon EC2 instances.
- If your instance is part of an Amazon EC2 Auto Scaling group, then the instance might terminate when you stop the instance. When you launch the instance with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk, your instance might be part of an AWS Auto Scaling group. In this scenario, instance termination 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.
- 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 Amazon Route 53, then you might need to update the Route 53 DNS records when the public IP address changes.
Note: It's a best practice to create a backup of your EBS volume before you begin the resolution steps.
To convert the default MBR partitioning scheme of a CentOS EC2 instance to GPT, complete the following steps:
-
Open the Amazon EC2 console.
-
Launch an instance from an AWS Marketplace Amazon Machine Image (AMI) that runs CentOS 7.
-
In the same Availability Zone as the first instance, launch a second instance from the same CentOS AMI that has a 3-TiB root volume.
Note: If you already have a CentOS 7 instance, then 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. -
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, then 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 instance type, then the device name appears as /dev/sdf or /dev/sda. If you use the Nitro instance type, then the device name appears as /dev/nvme0n1 or /dev/nvme1n1. -
Start the instance that you launched in step 2, and then connect to it with SSH.
-
To view the root partition of /dev/sdf, use the lsblk command. The root partition of /dev/sdf is only 2-TiB, as shown in the following example:
# 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 "/", as shown in the following example. If this occurs, stop and start the instance 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 -
To convert the partition table from MBR to GPT, use the gdisk tool:
# 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!Note: To install the gdisk tool, run the following command:
sudo yum install gdisk -y -
To create a GPT partition, run the following commands at the prompts. Input 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 this example, ef02 is the BIOS boot partition number.
-
To delete the root partition, run the following commands at the prompts:
Command (? for help): d Partition number (1-128): 1 -
To recreate the root partition to 3-TiB, run the following commands at the prompts. In the First sector, Last sector, and Hex code or GUID prompts, input 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' -
To save the GPT partition table, run 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 following command:
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 -
To check that the file system of device /dev/xvdf1 is correct, run the file system check and repair tool command.
CentOS 7:# 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 doneCentOS 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 -
To resize the file system to extend it to 3-TiB, run the xfs_growfs or resize2fs command.
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 786431739CentOS 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. -
Install Grub on the device /dev/xvdf1 and configure it with the following commands.
Note: Grub installation isn't required for CentOS 6. If you use CentOS 6, then skip to step 15.
CentOS 7:sudo mount --bind /proc /mnt/procsudo 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 -
Stop the instance.
-
Detach the volume /dev/xvdf from the stopped instance.
-
Attach the volume /dev/xvdf back to its original instance as /dev/sda1.
-
Start the original instance, and then connect to it with SSH.
-
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
Relevant content
- Accepted Answerasked 2 years ago
- Accepted Answerasked a year ago
- asked 2 years ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
