Larger than 2 TB disks not possible

[George]

=== Begin SRU Template ===
[Impact]
Growpart will not grow a partition past the 2TB mark.
The code to do this is present by design for MBR partitioned disks but
was active both for MBR and for GPT.

The primary impact is that guests with very large root disks will
not have their root filesystem grown completely.

[Test Case]
There is a test case in cloud-utils 'test/test-growpart'.
It can be invoked to test this path.

a. Install cloud-guest-utils.
# add -proposed or otherwise add apt to have correct version.
apt-get update
apt-get install cloud-guest-utils
dpkg-query --show cloud-guest-utils

b. get test case

url=https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/download/head:/testgrowpart-20130228125003-ejkrb587l0vw3eep-2/test-growpart
wget "$url" -O test-growpart
chmod 755 test-growpart

c. run test case growing from 1TB disk to 5TB disk.
## Note you do not want to run this on an encrypted disk as it would
## actually take 5TB and would be terribly slow.
$ sudo PT_TYPE=gpt DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart

This should result in a 5TB filesystem.

d. make sure MBR doesnt grow past 2TB.
$ sudo PT_TYPE=dos DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart

This should show a warning about the disk having unused space,
and should result in a 2TB filesystem.

e. Verify that cloud image correctly resizes.
 1. Get a cloud image of correct release with cloud-guest-utils updated inside it
    get-proposed-cloudimg can automate that for you.
    https://github.com/cloud-init/ubuntu-sru/blob/master/bin/get-proposed-cloudimg
    $ get-proposed-cloudimg --proposed --upgrade=cloud-guest-utils \
       xenial xenial-proposed.img
 2. create a disk larger than 2TB
    qemu-img create -f qcow2 -b xenial-proposed.img large-disk.img 5T
 3. boot image with large disk and nocloud seed.
    $ cat > my-user-data <<"EOF"
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
EOF

    $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
    $ cloud-localds my-seed.img my-user-data my-meta-data
    $ qemu-system-x86_64 -enable-kvm \
        -device virtio-net-pci,netdev=net00 -netdev user,id=net00 \
        -drive file=large-disk.img,id=disk00,if=none,index=0 \
        -device virtio-blk,drive=disk00,serial=large-disk.img \
        -drive file=my-seed.img,id=disk01,if=none,index=1 \
        -device virtio-blk,drive=disk01,serial=my-seed.img \
        -snapshot -m 1G -nographic

Then log in as 'ubuntu' with 'passw0rd'
and run 'df -h /' to verify 5TB root filesystem.

[Regression Potential]
The most likely regression here would be to have mbr attempt to grow
past 2TB and fail. This is called out in test case part 'd' above.

[Other Info]
Upstream merge proposal:
  https://code.launchpad.net/~smoser/cloud-utils/trunk.1762748-gpt-big-disks/+merge/343155

Upstream commit:
  https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/revision/323
=== End SRU Template ===

Hi,

We run Openstack and need to provide instances that have very large root disks (> 2 TB) and it looks like cloud-init doesn't want to use the entire space.

The regular Ubuntu cloud image has MBR and it doesn't see more than 2 TB, but even the GPT version (http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-uefi1.img) still fails to see more than 2 TB.

root@ubuntu-16:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 121G 0 121G 0% /dev
tmpfs 25G 8.6M 25G 1% /run
/dev/vda1 2.0T 857M 2.0T 1% /
tmpfs 121G 0 121G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121G 0 121G 0% /sys/fs/cgroup
tmpfs 25G 0 25G 0% /run/user/1000

root@ubuntu-16:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 5583GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
 1 1049kB 2199GB 2199GB primary ext4 boot

root@ubuntu-16:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 5.1T 0 disk
└─vda1 253:1 0 2T 0 part /
root@ubuntu-16:~# dpkg -l | grep cloud-init
ii cloud-init 17.2-35-gf576b2a2-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.5 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.5 all write a network interface file in /run for BOOTIF

The cloud-init.log looks like the disk growing and file system resizing went fine:

018-04-10 14:14:31,332 - stages.py[DEBUG]: Running module growpart (<module 'cloudinit.config.cc_growpart' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py'>) with frequency always
2018-04-10 14:14:31,332 - handlers.py[DEBUG]: start: init-network/config-growpart: running config-growpart with frequency always
2018-04-10 14:14:31,332 - helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x7f98107d9a90>)
2018-04-10 14:14:31,332 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg. Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices': ['/']}
2018-04-10 14:14:31,332 - util.py[DEBUG]: Running command ['growpart', '--help'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,352 - util.py[DEBUG]: Reading from /proc/1192/mountinfo (quiet=False)
2018-04-10 14:14:31,352 - util.py[DEBUG]: Read 2621 bytes from /proc/1192/mountinfo
2018-04-10 14:14:31,353 - util.py[DEBUG]: Running command ['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,355 - util.py[DEBUG]: Running command ['running-in-container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,356 - util.py[DEBUG]: Running command ['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,357 - util.py[DEBUG]: Reading from /proc/1/environ (quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 153 bytes from /proc/1/environ
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from /proc/self/status (quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 906 bytes from /proc/self/status
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from /sys/class/block/vda1/partition (quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 2 bytes from /sys/class/block/vda1/partition
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/dev (quiet=False)
2018-04-10 14:14:31,359 - util.py[DEBUG]: Read 6 bytes from /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/dev
2018-04-10 14:14:31,359 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,504 - util.py[DEBUG]: Running command ['growpart', '/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,567 - util.py[DEBUG]: resize_devices took 0.215 seconds
2018-04-10 14:14:31,567 - cc_growpart.py[INFO]: '/' resized: changed (/dev/vda, 1) from 2359296000 to 2199022206464
2018-04-10 14:14:31,567 - handlers.py[DEBUG]: finish: init-network/config-growpart: SUCCESS: config-growpart ran successfully
2018-04-10 14:14:31,567 - stages.py[DEBUG]: Running module resizefs (<module 'cloudinit.config.cc_resizefs' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_resizefs.py'>) with frequency always
2018-04-10 14:14:31,568 - handlers.py[DEBUG]: start: init-network/config-resizefs: running config-resizefs with frequency always
2018-04-10 14:14:31,568 - helpers.py[DEBUG]: Running config-resizefs using lock (<cloudinit.helpers.DummyLock object at 0x7f9810347390>)
2018-04-10 14:14:31,568 - schema.py[DEBUG]: Ignoring schema validation. python-jsonschema is not present
2018-04-10 14:14:31,568 - util.py[DEBUG]: Reading from /proc/1192/mountinfo (quiet=False)
2018-04-10 14:14:31,568 - util.py[DEBUG]: Read 2621 bytes from /proc/1192/mountinfo
2018-04-10 14:14:31,569 - cc_resizefs.py[DEBUG]: resize_info: dev=/dev/vda1 mnt_point=/ path=/
2018-04-10 14:14:31,569 - util.py[DEBUG]: Running command ['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,571 - util.py[DEBUG]: Running command ['running-in-container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,572 - util.py[DEBUG]: Running command ['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,574 - util.py[DEBUG]: Reading from /proc/1/environ (quiet=False)
2018-04-10 14:14:31,574 - util.py[DEBUG]: Read 153 bytes from /proc/1/environ
2018-04-10 14:14:31,574 - util.py[DEBUG]: Reading from /proc/self/status (quiet=False)
2018-04-10 14:14:31,574 - util.py[DEBUG]: Read 906 bytes from /proc/self/status
2018-04-10 14:14:31,575 - cc_resizefs.py[DEBUG]: Resizing / (ext4) using resize2fs /dev/vda1
2018-04-10 14:14:31,575 - util.py[DEBUG]: Running command ('resize2fs', '/dev/vda1') with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:47,291 - util.py[DEBUG]: Resizing took 15.716 seconds
2018-04-10 14:14:47,291 - cc_resizefs.py[DEBUG]: Resized root filesystem (type=ext4, val=True)
2018-04-10 14:14:47,292 - handlers.py[DEBUG]: finish: init-network/config-resizefs: SUCCESS: config-resizefs ran successfully

On the other hand, the Ubuntu 14.04 image with GPT works fine though and resizes the root to use the entire disk space provided, despite some errors in the cloud-init.log file:

root@14-gpt:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 121G 12K 121G 1% /dev
tmpfs 25G 352K 25G 1% /run
/dev/vda1 5.0T 811M 4.8T 1% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 121G 0 121G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/vda15 105M 3.2M 102M 4% /boot/efi

root@14-gpt:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 5583GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
14 1049kB 5243kB 4194kB bios_grub
15 5243kB 116MB 111MB fat32 boot
 1 116MB 5583GB 5583GB ext4

root@14-gpt:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 5.1T 0 disk
├─vda1 253:1 0 5.1T 0 part /
├─vda14 253:14 0 4M 0 part
└─vda15 253:15 0 106M 0 part /boot/efi

root@14-gpt:~# dpkg -l | grep cloud-init
ii cloud-init 0.7.5-0ubuntu1.22 all Init scripts for cloud instances

Errors in the cloud-init.log file:

2018-04-10 14:42:40,537 - importer.py[DEBUG]: Looking for modules ['cc_growpart', 'cloudinit.config.cc_growpart'] that have attributes ['handle']
2018-04-10 14:42:40,538 - importer.py[DEBUG]: Failed at attempted import of 'cc_growpart' due to: No module named cc_growpart
2018-04-10 14:42:40,538 - importer.py[DEBUG]: Found cc_growpart with attributes ['handle'] in ['cloudinit.config.cc_growpart']
2018-04-10 14:42:40,538 - importer.py[DEBUG]: Looking for modules ['cc_resizefs', 'cloudinit.config.cc_resizefs'] that have attributes ['handle']
2018-04-10 14:42:40,538 - importer.py[DEBUG]: Failed at attempted import of 'cc_resizefs' due to: No module named cc_resizefs
2018-04-10 14:42:40,539 - importer.py[DEBUG]: Found cc_resizefs with attributes ['handle'] in ['cloudinit.config.cc_resizefs']
2018-04-10 14:42:40,539 - importer.py[DEBUG]: Looking for modules ['cc_set_hostname', 'cloudinit.config.cc_set_hostname'] that have attributes ['handle']
2018-04-10 14:42:40,539 - importer.py[DEBUG]: Failed at attempted import of 'cc_set_hostname' due to: No module named cc_set_hostname
2018-04-10 14:42:40,539 - importer.py[DEBUG]: Found cc_set_hostname with attributes ['handle'] in ['cloudinit.config.cc_set_hostname']
2018-04-10 14:42:40,539 - importer.py[DEBUG]: Looking for modules ['cc_update_hostname', 'cloudinit.config.cc_update_hostname'] that have attributes ['handle']
2018-04-10 14:42:40,540 - importer.py[DEBUG]: Failed at attempted import of 'cc_update_hostname' due to: No module named cc_update_hostname
2018-04-10 14:42:40,540 - importer.py[DEBUG]: Found cc_update_hostname with attributes ['handle'] in ['cloudinit.config.cc_update_hostname']
2018-04-10 14:42:40,540 - importer.py[DEBUG]: Looking for modules ['cc_update_etc_hosts', 'cloudinit.config.cc_update_etc_hosts'] that have attributes ['handle']
2018-04-10 14:42:40,540 - importer.py[DEBUG]: Failed at attempted import of 'cc_update_etc_hosts' due to: No module named cc_update_etc_hosts
2018-04-10 14:42:40,540 - importer.py[DEBUG]: Found cc_update_etc_hosts with attributes ['handle'] in ['cloudinit.config.cc_update_etc_hosts']
2018-04-10 14:42:40,540 - importer.py[DEBUG]: Looking for modules ['cc_ca_certs', 'cloudinit.config.cc_ca_certs'] that have attributes ['handle']
2018-04-10 14:42:40,541 - importer.py[DEBUG]: Failed at attempted import of 'cc_ca_certs' due to: No module named cc_ca_certs
2018-04-10 14:42:40,541 - importer.py[DEBUG]: Found cc_ca_certs with attributes ['handle'] in ['cloudinit.config.cc_ca_certs']
2018-04-10 14:42:40,541 - importer.py[DEBUG]: Looking for modules ['cc_rsyslog', 'cloudinit.config.cc_rsyslog'] that have attributes ['handle']
2018-04-10 14:42:40,541 - importer.py[DEBUG]: Failed at attempted import of 'cc_rsyslog' due to: No module named cc_rsyslog
2018-04-10 14:42:40,542 - importer.py[DEBUG]: Found cc_rsyslog with attributes ['handle'] in ['cloudinit.config.cc_rsyslog']
2018-04-10 14:42:40,542 - importer.py[DEBUG]: Looking for modules ['cc_users_groups', 'cloudinit.config.cc_users_groups'] that have attributes ['handle']
2018-04-10 14:42:40,542 - importer.py[DEBUG]: Failed at attempted import of 'cc_users_groups' due to: No module named cc_users_groups
2018-04-10 14:42:40,542 - importer.py[DEBUG]: Found cc_users_groups with attributes ['handle'] in ['cloudinit.config.cc_users_groups']
2018-04-10 14:42:40,542 - importer.py[DEBUG]: Looking for modules ['cc_ssh', 'cloudinit.config.cc_ssh'] that have attributes ['handle']
2018-04-10 14:42:40,542 - importer.py[DEBUG]: Failed at attempted import of 'cc_ssh' due to: No module named cc_ssh
2018-04-10 14:42:40,543 - importer.py[DEBUG]: Found cc_ssh with attributes ['handle'] in ['cloudinit.config.cc_ssh']
2018-04-10 14:42:40,543 - importer.py[DEBUG]: Looking for modules ['ubuntu', 'cloudinit.distros.ubuntu'] that have attributes ['Distro']
2018-04-10 14:42:40,543 - importer.py[DEBUG]: Failed at attempted import of 'ubuntu' due to: No module named ubuntu
2018-04-10 14:42:40,543 - importer.py[DEBUG]: Found ubuntu with attributes ['Distro'] in ['cloudinit.distros.ubuntu']
2018-04-10 14:42:40,543 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.ubuntu.Distro'>
2018-04-10 14:42:40,544 - helpers.py[DEBUG]: Running config-migrator using lock (<cloudinit.helpers.DummyLock object at 0x7fc035363a90>)
2018-04-10 14:42:40,544 - cc_migrator.py[DEBUG]: Migrated 0 semaphore files to there canonicalized names
2018-04-10 14:42:40,544 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/fb741604-966c-4142-8d81-904ab27ac5bd/sem/config_seed_random - wb: [420] 19 bytes
2018-04-10 14:42:40,544 - helpers.py[DEBUG]: Running config-seed_random using lock (<FileLock using file '/var/lib/cloud/instances/fb741604-966c-4142-8d81-904ab27ac5bd/sem/config_seed_random'>)
2018-04-10 14:42:40,544 - cc_seed_random.py[DEBUG]: seed_random: adding 512 bytes of random seed entropy to /dev/urandom
2018-04-10 14:42:40,544 - util.py[DEBUG]: Writing to /dev/urandom - ab: [None] 512 bytes
2018-04-10 14:42:40,545 - util.py[DEBUG]: Running command ['pollinate', '-q'] with allowed return codes [0] (shell=False, capture=False)
2018-04-10 14:42:41,192 - helpers.py[DEBUG]: Running config-bootcmd using lock (<cloudinit.helpers.DummyLock object at 0x7fc035302610>)
2018-04-10 14:42:41,192 - cc_bootcmd.py[DEBUG]: Skipping module named bootcmd, no 'bootcmd' key in configuration
2018-04-10 14:42:41,192 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/fb741604-966c-4142-8d81-904ab27ac5bd/sem/config_write_files - wb: [420] 19 bytes
2018-04-10 14:42:41,192 - helpers.py[DEBUG]: Running config-write-files using lock (<FileLock using file '/var/lib/cloud/instances/fb741604-966c-4142-8d81-904ab27ac5bd/sem/config_write_files'>)
2018-04-10 14:42:41,192 - cc_write_files.py[DEBUG]: Skipping module named write-files, no/empty 'write_files' key in configuration
2018-04-10 14:42:41,193 - helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x7fc035302510>)
2018-04-10 14:42:41,193 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg. Using default: {'ignore_growroot_disabled': False, 'mode': 'auto', 'devices': ['/']}
2018-04-10 14:42:41,193 - util.py[DEBUG]: Running command ['growpart', '--help'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:42:41,197 - util.py[DEBUG]: Reading from /proc/945/mountinfo (quiet=False)
2018-04-10 14:42:41,197 - util.py[DEBUG]: Read 1174 bytes from /proc/945/mountinfo
2018-04-10 14:42:41,197 - util.py[DEBUG]: Reading from /sys/class/block/vda1/partition (quiet=False)
2018-04-10 14:42:41,197 - util.py[DEBUG]: Read 2 bytes from /sys/class/block/vda1/partition
2018-04-10 14:42:41,197 - util.py[DEBUG]: Reading from /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/dev (quiet=False)
2018-04-10 14:42:41,197 - util.py[DEBUG]: Read 6 bytes from /sys/devices/pci0000:00/0000:00:04.0/virtio1/block/vda/dev
2018-04-10 14:42:41,197 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:42:41,223 - util.py[DEBUG]: Running command ['growpart', '/dev/vda', '1'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:42:42,276 - util.py[DEBUG]: resize_devices took 1.080 seconds
2018-04-10 14:42:42,276 - cc_growpart.py[INFO]: '/' resized: changed (/dev/vda, 1) from 2144321024 to 5583341075968

I also attached the output generated from "cloud-init collect-logs" from a Ubuntu 16.04 (GPT) instance deployed with a disk of 5.1 TB

Thank you.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-utils - 0.30-0ubuntu4

---------------
cloud-utils (0.30-0ubuntu4) bionic; urgency=medium

  * sync to trunk at 323.
    - growpart: fix bug that stopped GPT disks from being grown past 2TB.
      (LP: #1762748)

 -- Scott Moser <email address hidden> Thu, 12 Apr 2018 23:36:41 -0400

[Scott Moser (smoser)]

I've just uploaded to
 - xenial (16.04) cloud-utils_0.27-0ubuntu25.1_source.changes
   https://git.launchpad.net/~smoser/ubuntu/+source/cloud-utils/log/?h=bug/1762748-xenial-growpart-past-2TB-disks
 - artful (17.10) cloud-utils_0.30-0ubuntu2.1_source.changes
   https://git.launchpad.net/~smoser/ubuntu/+source/cloud-utils/log/?h=bug/1762748-artful-growpart-past-2TB-disks

[Robie Basak (racb)]

Hello George, or anyone else affected,

Accepted cloud-utils into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cloud-utils/0.27-0ubuntu25.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Robie Basak (racb)]

Hello George, or anyone else affected,

Accepted cloud-utils into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cloud-utils/0.30-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[George (lmihaiescu)]

Hi,

Is there a cloud image built for xenial with this new version of cloud-utils that we could use for testing?

If not, is there a way we can install the fix in a running Ubuntu 16.04 VM that started from a 5 TB disk and was not properly resized, and force it to run the cloud-init script from the new package again upon reboot?

The last option would be to start a Ubuntu 16.04 VM, install the new cloud-utils and take a snapshot. Then use the snapshot to start an xxlarge VM with a 5 TB root disk and see if it gets properly resized.

Thank you for all your work fixing this bug,
George

[Jared Baker (shubjero)]

I have tested cloud-guest-utils version 0.27-0ubuntu25.1 and it appears to allow instances with disks larger than 2TB to be deployed properly.

My testing was to deploy an instance with a small root disk, then install the patched cloud-guest-utils on to the instance. I would then take a snapshot of the instance and re-deploy it as a larger VM with a >2TB root disk.

I hope to see this patched version of cloud-guest-utils pushed to the Xenial ubuntu cloud images soon :)

Thank you very much for your work

[Scott Moser (smoser)]

Marking verification-done-xenial based on Jared's comment.

George, get-proposed-cloudimg can download and update a cloud-image for you.
see more info in the test example above.

get-proposed-cloudimg --proposed --upgrade=cloud-guest-utils \
  xenial xenial-proposed.img

[Scott Moser (smoser)]

I'm marking verification-done for xenial and artful based on my attached logs and xenial based on Jared's comment above.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-utils - 0.27-0ubuntu25.1

---------------
cloud-utils (0.27-0ubuntu25.1) xenial; urgency=medium

  * debian/patches/lp-1762748-growpart-grow-past-2TB-disks.patch:
    growpart: fix bug that stopped GPT disks from being grown past 2TB.
    (LP: #1762748)

 -- Scott Moser <email address hidden> Thu, 19 Apr 2018 10:56:47 -0400

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for cloud-utils has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-utils - 0.30-0ubuntu2.1

---------------
cloud-utils (0.30-0ubuntu2.1) artful; urgency=medium

  * debian/patches/lp-1762748-growpart-grow-past-2TB-disks.patch:
    growpart: fix bug that stopped GPT disks from being grown past 2TB.
    (LP: #1762748)

 -- Scott Moser <email address hidden> Thu, 19 Apr 2018 10:55:10 -0400

[Scott Moser (smoser)]

This bug is believed to be fixed in cloud-utils in version 0.31. If this is still a problem for you, please make a comment and set the state back to New

Thank you.