GPT disk growroot fails in version .027 cloud-utills

[ritesh nanda]

Cloud-utils version

ii cloud-guest-utils 0.27-0ubuntu9.1 cloud guest utilities
ii cloud-image-utils 0.27-0ubuntu9.1 cloud image management utilities
ii cloud-init 0.7.5-0ubuntu1 Init scripts for cloud instances
ii cloud-initramfs-growroot 0.25ubuntu1.12.04.1 automatically resize the root partition on first boot
ii cloud-utils 0.27-0ubuntu9.1 metapackage for installation of upstream cloud-utils source

When trying to provision a baremetal with disk greater than 2TB and using GPT.

We use Ironic Python agent which basically creates a config drive which is basically a 64 Mb disk at the end of the disk.

Then once the installation is complete box boots back , growpart fails giving a error

Now when trying growpart runs it fails as

growpart /dev/sda 3
failed [sgdisk_mod:4] sgdisk --move-second-header --delete=3 --new=3:8790016:22501064664 --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 --partition-guid=3:78CD977B-AE3C-42D7-AF7E-273F8C807BC5 --change-name=3:Linux filesystem /dev/sda
Could not create partition 3 from 8790016 to 22501064664
Could not change partition 3's type code to 0FC63DAF-8483-4772-8E79-3D69D8477DE4!
Unable to set partition 3's name to 'Linux filesystem'!
Error encountered; not saving changes.
FAILED: disk=/dev/sda partition=3: 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.

Below is the example of the disk Layout.

gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 22501195776 sectors, 10.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): D7F2691D-DDB7-4F22-BA98-49AC583C9844
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 22501195742
Partitions will be aligned on 8-sector boundaries
Total free space is 22165520377 sectors (10.3 TiB)

Number Start (sector) End (sector) Size Code Name
   1 2048 976895 476.0 MiB 8300 Linux filesystem
   2 976896 8790015 3.7 GiB 8200 Linux swap
   3 8790016 335544286 155.8 GiB 8300 Linux filesystem
   4 34 2047 1007.0 KiB EF02 BIOS boot partition
   5 22501064664 22501195742 64.0 MiB 8300 (Config drive is created at sector 22501064664 )

Then i have to change the sector size by one less for which config drive was created.

sgdisk --move-second-header --delete=3 --new=3:8790016:22501064663 --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 --partition-guid=3:78CD977B-AE3C-42D7-AF7E-273F8C807BC5 --change-name=3:"Linux filesystem" /dev/sda
***** Appears to have gone OK ****

Help would be appreciated.

[David Medberry (med)]

http://bazaar.launchpad.net/~smoser/ubuntu/zesty/cloud-utils/pkg/view/head:/bin/growpart#L292

commenting this out makes growpart work fine on >2TB GPT instance. Tested with 3T and 4T (but seems to work in general).

The mbr_max_512 shouldn't really be considered on a GPT disk, it's not applicable.

[David Medberry (med)]

Checking to see if this is still an issue in Z and A release names with 0.30 but a quick visual says it will be.

[David Medberry (med)]

Confirmed, still exists in 0.30:
cloud-guest-utils_0.30-0ubuntu2_all.deb

and commenting the same lines still works (in this case, not a general solution as it would cause bad behavior on DOS/MBR partition tables.) Working up a patch for that.

[David Medberry (med)]

Thought it might be handy to throw in a use case for such a large root volume. Some "cloud" setups don't allow for attached volumes or any sort of attached block storage and only have a root volume (but are run on beefy enough servers with large disks to provide 100T of space to VMs.) In this isolated case, the best option is to setup and run a vm with GPT partitioned root disk (using something like: https://lists.ubuntu.com/archives/ubuntu-cloud/2013-December/000929.html and specifically http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-uefi1.img )

[Fred De Backer (freddebacker)]

We have this issue as well. The rootcause is that it's trying to grow the partition using the [start of next] sector as end sector for the partition instead of [start of next - 1].

[Fred De Backer (freddebacker)]

See https://code.launchpad.net/~freddebacker/cloud-utils/cloud-utils/+merge/354305

[Launchpad Janitor (janitor)]

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

---------------
cloud-utils (0.30-0ubuntu9) cosmic; urgency=medium

  * debian/tests/control: fix typo in dependencies 'gdisk', not 'sgdisk'

 -- Scott Moser <email address hidden> Thu, 06 Sep 2018 11:33:24 -0400

[Scott Moser (smoser)]

This was actually fixed in cloud-utils - 0.30-0ubuntu6, but a slew of my errors meant it didnt leave -proposed until 0ubuntu9.

----------------
cloud-utils (0.30-0ubuntu6) cosmic; urgency=medium

  * sync to trunk at 333:
    - growpart: fix bug when resizing a middle partition with sgdisk.
      (LP: #1706751) [Fred De Backer]
    - test/test-mic: fix typo
    - run test for mount-image-callback
    - debian/tests/control: mention dependencies on gdisk and fdisk.
    - mount-image-callback: mention --help and -C/--cd-mountpoint in Usage

[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.