Bug 1155742

Summary: RHEL 6.x-HVM and 7 EC2 AMIs root volume resizing is broken
Product: Red Hat Enterprise Linux 7 Reporter: Irving Popovetsky <irving>
Component: cloud-initAssignee: Lars Kellogg-Stedman <lars>
Status: CLOSED DUPLICATE QA Contact: mkovacik
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: irving, it-team, mkovacik, ohudlick, tlavigne
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-22 10:27:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Irving Popovetsky 2014-10-22 18:09:26 UTC
Description of problem:
RHEL AMIs should be able to be launched with a larger root volume, and they should automatically resize the root volume to fill the available space using cloud-init and growpart.   

This has worked well with the RHEL 6.5 PV AMIs,  but no longer works with RHEL 6 HVM and RHEL 7 HVM AMIs which now use GPT-partitioned root volumes.

Version-Release number of selected component (if applicable):
cloud-init 0.7.5

How reproducible:   100% reproducible


Steps to Reproduce:
1. In the EC2 console, select an AMI based on the RHEL-6.5_GA_HVM-20140929-x86_64-11-Hourly2-GP2, RHEL-6.6_HVM_GA-20141017-x86_64-1-Hourly2-GP2 or RHEL-7.0_HVM_GA-20141017-x86_64-1-Hourly2-GP2  
2.  Select a larger than default root volume size (ex: 10 GB)
3.  Launch it

Actual results:

Root volume remains 5.8 GB
/var/log/cloud-init.log says:
Oct 21 18:14:09 ip-rhel-backend2 cloud-init: 2014-10-21 18:14:09,664 - util.py[WARNING]: Failed: growpart /dev/xvda 2

A reboot is required for the partition table to be re-read:

[root@ip-33-33-33-96 ~]# growpart /dev/xvda 2
failed [pt_update:1] pt_update /dev/xvda 2
partx: /dev/xvda: error updating partition 2
FAILED: disk=/dev/xvda partition=2: failed to repartition
***** WARNING: Resize failed, attempting to revert ******
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
***** Appears to have gone OK ****

[root@ip-33-33-33-96 ~]# growpart -u off /dev/xvda 2 
CHANGED: disk=/dev/xvda partition=2: start=4096 old: size=12582911,end=12587007 new: size=25161694,end=25165790

[root@ip-33-33-33-96 ~]# lsblk 
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   12G  0 disk 
├─xvda1 202:1    0    1M  0 part 
└─xvda2 202:2    0    6G  0 part /
xvdb    202:16   0 37.5G  0 disk /mnt

[root@ip-33-33-33-96 ~]# partx -v --update 2 /dev/xvda
partition: 2, disk: /dev/xvda, lower: 2, upper: 2
/dev/xvda: partition table type 'gpt' detected
partx: /dev/xvda: updating partition #2 failed: Device or resource busy
partx: /dev/xvda: error updating partition 2


Expected results:

root volume resizes to 10GB automatically on boot

Additional info:

1. the gdisk package is not installed, so growpart 
2. RHEL6 partx command doesn't support the -u (--update) option
3. RHEL7 partx does support the -u option, but it always fails with a "device or resource busy"

Comment 3 IT Team 2015-01-07 20:03:11 UTC
Any estimated date to get this bug fixed?

Comment 5 mkovacik 2015-01-22 10:27:55 UTC
Closing in favor of Bug #1162228 which contains situation analysis and depends on already identified issues.
For RHEL6.x GPT amis please refer to Bug #1110029

*** This bug has been marked as a duplicate of bug 1162228 ***

Comment 6 IT Team 2015-01-22 13:49:25 UTC
We're not authorized to access Bug #1162228 or #1110029.

Comment 7 James King 2015-06-11 16:40:11 UTC
Hello,

Is there a work around for this?  Unfortunately mortals are not allowed to view https://bugzilla.redhat.com/show_bug.cgi?id=1162228

Thanks

Comment 8 mkovacik 2015-11-04 10:24:39 UTC
Sorry for late response, this should be fixed now for both RHEL6 and 7 AMIs.

Comment 9 Irving Popovetsky 2015-11-04 18:02:19 UTC
hey @mkovacik could you please confirm which AMIs introduced this fix?