Open ricab opened 11 months ago
Describe the bug After attempting to grow the disk of a core20- or core22-based instance, no partition is grown to reflect the new size.
$ multipass exec -n a -- sudo fdisk -l /dev/sda GPT PMBR size mismatch (10485759 != 14680063) will be corrected by write. The backup GPT table is not on the end of the device. Disk /dev/sda: 7 GiB, 7516192768 bytes, 14680064 sectors Disk model: QEMU HARDDISK 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: A63BB26A-5487-41C0-AF40-19150D00E322 Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M BIOS boot /dev/sda2 4096 2461695 2457600 1.2G EFI System /dev/sda3 2461696 3997695 1536000 750M Linux filesystem /dev/sda4 3997696 4063231 65536 32M Linux filesystem /dev/sda5 4063232 10485726 6422495 3.1G Linux filesystem
Note: tried with core as well, where the writable partition was properly resized, although disk reporting in info is wonky (13.7GiB).
core
info
To Reproduce How, and what happened?
multipass launch -n a core22
multipass stop a
multipass set local.a.disk=7G
multipass start a
multipass info a | grep Disk
multipass exec -n a -- sudo fdisk -l /dev/sda
Expected behavior The writable partition (/dev/sda5 above) would grow to use the available disk space.
/dev/sda5
Logs
set 15 22:24:13 ricab-laptop multipassd[173643]: Succeeded setting local.a.disk=7G
Additional info
multipass version
multipass info --all
Name: a State: Running IPv4: 10.195.134.80 Release: Ubuntu Core 22 Image hash: 1493fccb9d55 (Ubuntu Core 22) CPU(s): 1 Load: 0.00 0.00 0.00 Disk usage: 1.4GiB out of 4.8GiB Memory usage: 84.2MiB out of 951.9MiB Mounts: --
Name: b State: Running IPv4: 10.195.134.83 Release: Ubuntu Core 16 Image hash: db3a6130f46f (Ubuntu Core 16) CPU(s): 1 Load: 0.00 0.00 0.00 Disk usage: 1.1GiB out of 13.7GiB Memory usage: 32.2MiB out of 986.4MiB Mounts: --
Name: c State: Running IPv4: 10.195.134.175 Release: Ubuntu Core 20 Image hash: 4692ea67d73e (Ubuntu Core 20) CPU(s): 1 Load: 0.02 0.02 0.00 Disk usage: 1.0GiB out of 4.8GiB Memory usage: 97.2MiB out of 971.2MiB Mounts: --
- `multipass get local.driver`: qemu
Faced the same issue
Describe the bug After attempting to grow the disk of a core20- or core22-based instance, no partition is grown to reflect the new size.
Note: tried with
core
as well, where the writable partition was properly resized, although disk reporting ininfo
is wonky (13.7GiB).To Reproduce How, and what happened?
multipass launch -n a core22
multipass stop a
multipass set local.a.disk=7G
multipass start a
multipass info a | grep Disk
multipass exec -n a -- sudo fdisk -l /dev/sda
Expected behavior The writable partition (
/dev/sda5
above) would grow to use the available disk space.Logs
Additional info
multipass version
: 1.12.2multipass info --all
Name: b State: Running IPv4: 10.195.134.83 Release: Ubuntu Core 16 Image hash: db3a6130f46f (Ubuntu Core 16) CPU(s): 1 Load: 0.00 0.00 0.00 Disk usage: 1.1GiB out of 13.7GiB Memory usage: 32.2MiB out of 986.4MiB Mounts: --
Name: c State: Running IPv4: 10.195.134.175 Release: Ubuntu Core 20 Image hash: 4692ea67d73e (Ubuntu Core 20) CPU(s): 1 Load: 0.02 0.02 0.00 Disk usage: 1.0GiB out of 4.8GiB Memory usage: 97.2MiB out of 971.2MiB Mounts: --