Debian 10 image unable to grow disk image

[inconstante]

Launching from the Debian 10 image creates a VM with 20 GB disk, regardless of the flavor selection, whereas other images create VMs with larger disks.

Steps to reproduce:

1. Go to 'Instances'
2. Click on 'Launch instance'
3. Under the 'Source' tab select 'Debian 10 ppc64le'
4. Under the 'Flavor' tab select 'minicloud.max' (or other flavor with disk larger than 20 GB)
5. Quickly open the 'console' and see the following error, right after the kernel boots:

GROWROOT: NOCHANGE: partition 2 is size 37869568. it cannot be grown

Expected behavior:

With other images, e.g. Debian 9, the GROWROOT step succeeds:

GROWROOT: CHANGED: partition=2 start=16384 old size=10467328 end 10483712 new: 67772127

[steve8x8]

Currently (for at least three days now) there's no Debian 10 image available. Is this related?

[lcnzg]

Currently (for at least three days now) there's no Debian 10 image available. Is this related?

Yes, I disabled this image until I finish fixing this issue.
I think I used a wrong partition order when creating this image, so now the partition can't grow.

[steffen64g]

So I'm in a limbo state that I still have a snapshot taken from an un-grown Buster image - that therefore would still fit into a tiny vm (as reported in #16) - which I can continue using, but there's no way to start a new tiny instance with Buster?

[lcnzg]

but there's no way to start a new tiny instance with Buster

I reactivated the Debian 10 image now, but the bug still there.

[rpsene]

@lcnzg this may give you some ideas about the issue https://ask.openstack.org/en/question/51024/cloud-init-does-not-grow-the-partition-nor-the-filesystem/

[steffen64g]

Indeed:

# fdisk -lu
GPT PMBR size mismatch (41943039 != 167772159) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/vda: 80 GiB, 85899345920 bytes, 167772160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD696C9A-4666-4EF4-BD38-0F8AA36E994A

Device        Start      End  Sectors  Size Type
/dev/vda1      2048    16383    14336    7M PowerPC PReP boot
/dev/vda2     16384 37885951 37869568 18.1G Linux filesystem
/dev/vda3  37885952 41940991  4055040    2G Linux swap

the swap partition, directly at the end of the root fs partition, appears to prevent growing the 2nd partition. I haven't looked at the other images but suspect something went wrong especially for the Buster image - which may have been created using a different setup than the "older" other images?

So what would happen if I, on my own snapshot image, removed the swap partition completely (i.e., after swapoff)? A write operation in fdisk would fix the total disk size, and I'd be able to set up a new swap partition at the end of the resized vda disk, then restart the image to get the root fs resized?

Answering myself: it worked:

# fdisk -lu
Disk /dev/vda: 80 GiB, 85899345920 bytes, 167772160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD696C9A-4666-4EF4-BD38-0F8AA36E994A

Device         Start       End   Sectors  Size Type
/dev/vda1       2048     16383     14336    7M PowerPC PReP boot
/dev/vda2      16384 159999999 159983616 76.3G Linux filesystem
/dev/vda3  160000000 167772126   7772127  3.7G Linux swap

The trick, I guess, is to place the swap partition in front of the root one, which appears to be the case with the other images?