Hi Frederic, I've tried to reproduce this issue using cloud-utils (0.26-2) on Jessie:
root@virtualbox:~# growpart -v /dev/sda 1 geometry is -C 2610 -H 255 -S 63. total size=41929650 max_end=41929650 tot=41929650 pt_end=41943040 pt_start=1 pt_size=41943039 NOCHANGE: partition 1 could only be grown by -13390 [fudge=20480] And the output was a little bit different, but the result is the same, as it could not grow the partition. Then I've tried using cloud-utils (0.27-2) from Stretch on Jessie: root@virtualbox:~# growpart -v /dev/sda 1 update-partition set to true FAILED: GPT partition found but no sgdisk And after installing "gdisk": root@virtualbox:~# growpart -v /dev/sda 1 update-partition set to true found GPT partition table (id = ee) disk=/dev/sda partition=1: original sgdisk info: Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) Partition unique GUID: 4F846BCA-2671-486C-AFD7-6DBA157FDDD1 First sector: 2048 (at 1024.0 KiB) Last sector: 15624191 (at 7.5 GiB) Partition size: 15622144 sectors (7.4 GiB) Attribute flags: 0000000000000000 Partition name: '' Disk /dev/sda: 41943040 sectors, 20.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): D9C74796-7ED9-49AA-84C7-808685BC8ED7 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 41943006 Partitions will be aligned on 2048-sector boundaries Total free space is 26320829 sectors (12.6 GiB) Number Start (sector) End (sector) Size Code Name 1 2048 15624191 7.4 GiB 8300 disk=/dev/sda partition=1: pretend sgdisk info Disk /dev/sda: 41943040 sectors, 20.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): D9C74796-7ED9-49AA-84C7-808685BC8ED7 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 41943006 Partitions will be aligned on 2048-sector boundaries Total free space is 26320829 sectors (12.6 GiB) Number Start (sector) End (sector) Size Code Name 1 2048 15624191 7.4 GiB 8300 disk=/dev/sda partition=1: pt_start=2048 pt_end=15624191 pt_size=15622143 pt_max=41943006 last=41943006 disk=/dev/sda partition=1: code=0FC63DAF-8483-4772-8E79-3D69D8477DE4 guid=4F846BCA-2671-486C-AFD7-6DBA157FDDD1 name='' CHANGED: disk=/dev/sda partition=1: start=2048 old: size=15622143,end=15624191 new: size=41940958,end=41943006 Everything went fine and "resize2fs" is now able to expand the filesystem: root@virtualbox:~# resize2fs /dev/sda1 resize2fs 1.42.12 (29-Aug-2014) Filesystem at /dev/sda1 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 2 The filesystem on /dev/sda1 is now 5242619 (4k) blocks long. root@virtualbox:~# df -h | grep sda1 /dev/sda1 20G 951M 18G 5% / Then I've restored a snapshot, upgraded the machine to sid/unstable and tried again. Using cloud-utils (0.27-2) from Sid: root@virtualbox:~# growpart -v /dev/sda 1 update-partition set to true found MBR partition table (id = 0FC63DAF-8483-4772-8E79-3D69D8477DE4) total number of sectors of /dev/sda is 41943040 ## sfdisk --dump /dev/sda label: gpt label-id: D9C74796-7ED9-49AA-84C7-808685BC8ED7 device: /dev/sda unit: sectors first-lba: 34 last-lba: 41943006 /dev/sda1 : start= 2048, size= 15622144, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=4F846BCA-2671-486C-AFD7-6DBA157FDDD1 max_end=41943040 tot=41943040 pt_end=15624192 pt_start=2048 pt_size=15622144 attempt to resize /dev/sda failed. sfdisk output below: | The last usable GPT sector is 41943006, but 41943039 is requested. | Failed to add partition: Invalid argument | Backup files: | PMBR (offset 0, size 512): /tmp/growpart.YN5dSL/backup-sda-0x00000000.bak | GPT Header (offset 512, size 512): /tmp/growpart.YN5dSL/backup-sda-0x00000200.bak | GPT Entries (offset 1024, size 16384): /tmp/growpart.YN5dSL/backup-sda-0x00000400.bak | | Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 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: D9C74796-7ED9-49AA-84C7-808685BC8ED7 | | Old situation: | | Device Start End Sectors Size Type | /dev/sda1 2048 15624191 15622144 7.5G Linux filesystem | | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Script header accepted. | >>> Created a new GPT disklabel (GUID: D9C74796-7ED9-49AA-84C7-808685BC8ED7). | Leaving. | FAILED: failed to resize ***** WARNING: Resize failed, attempting to revert ****** 512+0 records in 512+0 records out 512 bytes copied, 0.00159423 s, 321 kB/s ***** Appears to have gone OK **** The partition could not be grown and now "resize2fs" can't do anything: root@virtualbox:~# resize2fs /dev/sda1 resize2fs 1.42.13 (17-May-2015) The filesystem is already 1952768 (4k) blocks long. Nothing to do! It has detected the partition table as MBR, although it is GPT, and failed because it tried to grow it using "sfdisk" instead of "sgdisk". You can see how the detection is done in the line 574 of "bin/growpart"[1]. The problem is that the option "--id" from "sfdisk" is not only deprecated: root@virtualbox:~# sfdisk --id /dev/sda 1 sfdisk: --id is deprecated in favour of --part-type 0FC63DAF-8483-4772-8E79-3D69D8477DE4 As its behaviour is different from older (< 2.26) versions of "sfdisk", where it used to return "ee" if a GPT partition was detected, as you can see in the output from Jessie: root@virtualbox:~# sfdisk --id /dev/sda 1 ee Upstream developers are aware of this and had already published a series of patches[2] to properly support newer (>= 2.26) versions of "fdisk", but there wasn't a new release of "cloud-utils" since then. We have a patch[3] applied to our last (0.27-2) package version, created a week before the one from upstream, but as we can see it doesn't work for GPT partitions. Last night I've tried to apply a patch from the revision 267[4] with no luck (it doesn't apply cleanly). I'm still looking at how this can be done, if fixing the detection will be enough or if we'll have to import the entire series (or at least most of it) of upstream patches. Then I guess it ill be a matter of adding "gdisk" as a package dependency. I'll keep you posted. P.s.: I already knew the Jessie situation since I did a triage for #784004[5]. The problem with Stretch/Sid is new to me. Regards, Tiago. [1]: https://anonscm.debian.org/cgit/collab-maint/cloud-utils.git/tree/bin/growpart?id=c92ff059a96548c6a752a8f3ef2e0fbe74cb08ec#n574 [2]: http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/changes?filter_file_id=growpart-20110225134600-d84xgz6209r194ob-1 [3]: https://anonscm.debian.org/cgit/collab-maint/cloud-utils.git/tree/debian/patches/also-support-sfdisk-2.26-and-higher.patch?id=8962cfc94acfe9d8a59fbea3d99ed0049152b710 [4]: http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/revision/267 [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784004#20 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
