Open inconstante opened 5 years ago
Currently (for at least three days now) there's no Debian 10 image available. Is this related?
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.
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?
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.
@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/
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?
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:
Expected behavior:
With other images, e.g. Debian 9, the
GROWROOT
step succeeds: