View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0017816Cloud Instance SIGcloud-initpublic2020-10-27 04:432020-11-20 07:02
Reporterdavdunc 
PrioritynormalSeveritymajorReproducibilityalways
Status acknowledgedResolutionopen 
Platformec2OSCentOSOS Version8
Summary0017816: 8.2.2004-20200611.2.aarch64 (latest) image partitioning prevents cloud-init config-growfs from expanding the root volume.
DescriptionWhen an instance is created with an EBS volume greater than 8GB, cloud-init is expected to grow the root partition, but because there is a backing partition on the image, the growfs completes successfully, but the root volume size remains unchanged.

# sfdisk -d /dev/nvme0n1
label: gpt
label-id: E97B9FFA-2C13-474E-A0E4-ABF1572CD20C
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 20971486

/dev/nvme0n1p1 : start= 2048, size= 1228800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=4C880299-6848-4FDE-9479-12D8F1410F6E, name="EFI System Partition"
/dev/nvme0n1p2 : start= 1230848, size= 16281600, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=7CA2D98D-3FD7-4B25-9400-854C5D9CC3F7
/dev/nvme0n1p3 : start= 17512448, size= 2048, type=21686148-6449-6E6F-744E-656564454649, uuid=69C14DB7-5A4D-4014-A565-5A894712AF1D

Root is on p2 and it turns out that the p3 prevents growfs
Steps To Reproducelaunch an aarch64 instance in any region using the instances with a volume configuration similar to the following:

    "BlockDeviceMappings": [
        {
            "DeviceName": "/dev/sda1",
            "Ebs": {
                "DeleteOnTermination": true,
                "VolumeType": "gp2",
                "VolumeSize": 20
            }
        }
    ],

I tested with the following:

    "ImageId": "ami-0c7ec43a152e9c107",
    "InstanceType": "t4g.small",
Additional InformationI reviewed the image-builder kickstart and I don't see anything creating this in the default configuration in this order, but I think something might be missing in the build.
Tags"nvme", ARM, AWS;AMI

Activities

arrfab

arrfab

2020-10-29 18:54

administrator   ~0037833

I pushed following commit for the centos 7 kickstart and regenerated cloud images (tested with aarch64) : https://git.centos.org/centos/kickstarts/c/fab7e017bab677e073e32e823aaa23fd7371e57a?branch=master
I then confirmed that imported image was automatically expanding root filesystem through growpart (now that gdisk was added, needed for gpt partition)
davdunc

davdunc

2020-10-30 04:22

reporter   ~0037834

Looked in CentOS-Stream-8-ec2 and found the same issue. Root is backed with a /boot partition.

[davdunc@ip-172-31-3-80 disk-images]$ guestfish <<_EOF_
add CentOS-Stream-ec2-8-20201019.1.aarch64.qcow2
run
list-filesystems
_EOF_

/dev/sda1: vfat
/dev/sda2: xfs
/dev/sda3: unknown
rm

rm

2020-11-19 21:25

reporter   ~0037947

Is there an update on this issue for CentOS 8?
arrfab

arrfab

2020-11-20 06:58

administrator   ~0037962

Let's hope that it will be done for the 8.3.2011 images, so let's tag @bstinson in this ticket
arrfab

arrfab

2020-11-20 07:02

administrator   ~0037963

and to not forget, I already pushed the same change we had for 7 and that works on the CentOS 7.9.2009 AMI aarch64 images :
https://git.centos.org/centos/kickstarts/c/d3bcf0591bf4e05004d697135a42e9fe9674c07a?branch=master

Issue History

Date Modified Username Field Change
2020-10-27 04:43 davdunc New Issue
2020-10-27 04:43 davdunc Tag Attached: "nvme"
2020-10-27 04:43 davdunc Tag Attached: ARM
2020-10-27 04:43 davdunc Tag Attached: AWS;AMI
2020-10-29 18:54 arrfab Note Added: 0037833
2020-10-30 04:22 davdunc Note Added: 0037834
2020-11-19 21:25 rm Note Added: 0037947
2020-11-20 06:58 arrfab Note Added: 0037962
2020-11-20 06:58 arrfab Status new => acknowledged
2020-11-20 07:02 arrfab Note Added: 0037963