Re: qemu-img resize --shrink seems to corrupt image although only free sectors at end of disk

[Nicolai Spohrer]

Solved! I just tried everything again with resizing to 76G and found out more while trying a few commands on GParted Live. Everything that follows is about resizing to 76G not 75G like previously (in case anyone is checking the sector counts ;) ).

`fdisk -l /dev/vda` gave one hint: `GPT PMBR size mismatch (167772159 != 159383551) will be corrected by write.` but only listed a single /dev/vda1 partition of type GPT with size 76G.

`gdisk -l /dev/vda` was even more helpful. It showed the correct partitions, after complaining quite a bit, and informed me about a few things:

```
Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk.
Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header.
[...]
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended.
```

That gdisk actually found the correct partition layout and showed it gave me enough confidence to try `sgdisk -e /dev/vda` to restore the backup partition table at the end of the disk.

Et voilà! After fixing the secondary partition table (and implicitly the incorrect size I assume), both fdisk and gdisk were happy to show the correct partition layout without any complaints.

Thank you,
Nicolai Spohrer

Am Di., 27. Dez. 2022 um 21:15 Uhr schrieb Nicolai Spohrer <nicolai@xeve.de>:

Hi all,

I am trying to shrink a qcow2 image without corrupting data. I already made sure, from inside the VM, that at the end of the disk there are ~8G worth of free sectors. The total disk size is 80G, so only the first ~72G are used as shown by fdisk:

```
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: EEB134A0-C938-46CA-9385-23A5F358AA64

Device       Start       End   Sectors Size Type
/dev/vda1     2048      4095      2048   1M BIOS boot
/dev/vda2     4096   4198399   4194304   2G Linux filesystem
/dev/vda3  4198400 150999040 146800641  70G Linux filesystem
```

The system works fine in this state and my understanding is that there is nothing relevant after sector 150999040 (~72G into the disk) other than the backup GPT table.

So my next step was to actually resize the disk (to 75G, so there's still a lot of buffer if there are some relevant sectors after vda3 ends):

```
# qemu-img info Ubuntu2.img
image: Ubuntu2.img
file format: qcow2
virtual size: 80 GiB (85899345920 bytes)
disk size: 39.9 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
   
# qemu-img resize --shrink Ubuntu2.img 75G
Image resized.

# qemu-img info Ubuntu2.img              
image: Ubuntu2.img
file format: qcow2
virtual size: 75 GiB (80530636800 bytes)
disk size: 39.9 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
```

This looked fine to me, and I proceeded to boot the system. Sadly, no partitions are recognized any longer and the boot to disk fails. With GParted Live I get the error "Invalid argument during seek for read on /dev/vda" (https://i.imgur.com/c45TZj4.png), and if I ignore that and an issue with one of the GPT tables then it shows everything as unallocated space. So I think something has gone wrong during the resize, hasn't it?

Interestingly enough, I can increase the size of the disk to 80G again with `qemu-img`, and afterwards the system works perfectly fine again. I get the error `The backup GPT table is corrupt` when running `fdisk -l /dev/vda`, which makes sense, but it can easily be restored by `sgdisk -e /dev/vda`.

I would be happy for any suggestion about what I might be doing wrong or how to fix this.

Thank you,
Nicolai Spohrer