Partition corruption detection does not work during first boot

See e.g. wb:17cdc07f4a6f6c7c2a3cd5a8b6a51f6c.

  1. The system believes it's first boot. This is strange because sgdisk --print /dev/sda complains about corruption but oh well, maybe.
  2. sgdisk --move-second-header --randomize-guids […] complains too, but somehow gets convinced it managed to do its job
  3. sgdisk --verify /dev/sda does not complain. This is the only time when we grep its output, looking for partitioning corruption. So we don't set the error to partitioning-corruption (arguably, there's apparently none anymore).
  4. The user tries to create a Persistent Storage, which fails in a way that suggests a counterfeit device:
Jan 30 20:40:44 amnesia tpsd[8168]: INFO:device.py:381: [15138-Create] Initializing LUKS header
Jan 30 20:40:44 amnesia tpsd[8168]: INFO:device.py:403: [15138-Create] Executing command cryptsetup
luksFormat --batch-mode --key-file=- --type=luks2 --pbkdf=argon2id --pbkdf-memory=1048576 --pbkdf-force-iterations=4 /dev/sda2
Jan 30 20:40:55 amnesia tpsd[8168]: INFO:device.py:936: [15138-Create] Executing command udevadm trigger --verbose --settle /dev/sda2
Jan 30 20:40:55 amnesia udisksd[6158]: Error getting '/dev/sda2' metadata_size: Failed to load device: Invalid argument (g-bd-crypto-error-quark, 0)
Jan 30 20:40:55 amnesia tpsd[16495]: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
Jan 30 20:40:55 amnesia tpsd[16495]: settle /sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
Jan 30 20:40:55 amnesia tpsd[8168]: INFO:device.py:412: [15138-Create] Unlocking partition
Jan 30 20:40:55 amnesia udisksd[6158]: Error getting '/dev/sda2' metadata_size: Failed to load device: Invalid argument (g-bd-crypto-error-quark, 0)
Jan 30 20:40:55 amnesia tpsd[8168]: ERROR:device.py:601: [15138-Create] Failed to unlock /dev/sda2: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sda2: Failed to load device's
parameters: Invalid argument

IMO in such a case we should set partitioning-corruption so we encourage the user to migrate to another USB stick, and we can collect data for #20705 (closed), in order to determine whether we should make this sort of failures fatal.

cc @anonym