UFS gpart recover ada0 fails with FreeBSD-provided disk images grown to 2.00 TB

[Cath O'Deray]

Steps:

1. <https://www.freebsd.org/where/>
2. download (for example) FreeBSD-11.4-RELEASE-amd64.vhd.xz
3. verify the checksum
4. extract FreeBSD-11.4-RELEASE-amd64.vhd
5. add the virtual disk to VirtualBox
6. grow the disk to 2.00 TB
7. create a machine to use the disk
8. boot in single user mode
9. gpart recover ada0

Expected:

• a good partition table

Actual result:

• CAM- and ATA-related errors, a corrupt or invalid secondary GPT table and an input/output error.

From geom_label: Remove an old sysinstall(8) workaround (2021-07-05):

We removed sysinstall(8) back in 2011, so this workaround should be long since unnecessary. This workaround can end up breaking cases that are hit in the real world, such as dd'ing a small pre-built disk image to a large partition that you intend to grow on first boot and uses a UFS disk label for / in its /etc/fstab (as the only reliable thing a raw UFS image can reference).

⚙ D30825 geom_label: Remove an old sysinstall(8) workaround

Might D30825/af433832f7520840c22edd1fe1266c1a5cb781ad be a fix for what's seen with gpart(8) with FreeBSD-provided images that are grown as described above?

 

[Alain De Vos]

Maximum size is normally 16TB - 1%

 

[Cath O'Deray]

Thanks, so 2 (two) should be OK.

PS I'd like to understand why gpart fails, and whether the recent commit is a fix.