Errors in GPT partitioning and fat32 partition

[2opremio]

gdisk and fsck find errors in the partitioning and fat32 partition:

% sudo fsck_msdos disk4s1
** /dev/rdisk4s1
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
** Phase 3 - Checking for Orphan Clusters
Free space in FSInfo block is unset (should be 4280)
Fix? [yn]

% sudo fsck.vfat /dev/disk4s1
fsck.fat 4.2 (2021-01-31)
Warning: Filesystem is FAT32 according to fat_length and fat32_length fields,
  but has only 31710 clusters, less than the required minimum of 65525.
  This may lead to problems on some systems.
Label in boot sector is 'Volume 0', but there is no volume label in root directory.
1) Remove label from boot sector
2) Copy label from boot sector to root directory
[12?q]?

% sudo gdisk /dev/disk4
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): v

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Warning: There is a gap between the main partition table (ending sector 33)
and the first usable sector (2048). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.
Identified 1 problems!
Command (? for help):

The gdisk problems are also reported by the linux kernel (although it still can access the disk). The can be fixed in gdisk by entering expert mode (x key) and then pressing j and e.

[2opremio]

The warning:

Warning: Filesystem is FAT32 according to fat_length and fat32_length fields,
  but has only 31710 clusters, less than the required minimum of 65525.
  This may lead to problems on some systems.

is fixed by #3

[andoma]

IIRC the Linux kernel also complain on this:

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

I'm not just sure how to do this correctly. If you just generate a (relative small) image, and write it out on a much larger disk, how is efimaker supposed to know this ahead of time? I wonder how other tools do this.

[2opremio]

I wonder if, unlike dd, etcher and friends do something more sophisticated than writing the file.

[andoma]

Apparently sgdisk -e /dev/sdX after writing the image to a disk will move the backup GPT sector to end of the disk. (Not tested myself)