Every image stage 06 packs has 4096-byte blocks, the size dm-verity reads it in

[DevomB]

The interim browser round (Distro 38735220159, batch 636e7fb) failed three acceptance parts on one error: a zone could not start on the probe image.

kryptikd: could not start zone "upimg": zone "upimg": mount ext4 at /run/kryptik/images/probe/<root hash>: Invalid argument (os error 22)

The three items:

• update-test: "the probe image did not run on B", and again after the rollback.
• update-test-production: the same on 1.0.1.
• install-test: "a zone runs the probe from the image the installer kept from the medium".

The copy and check steps before the mount all pass (list signature, sizes, hashes, the verity open). The mount itself is refused.

Cause. make_ext4 runs mke2fs without -b, and e2fsprogs 1.47.1's mke2fs.conf gives a file system under 512 MiB the small type, which is blocksize = 1024. The probe image is about 16 MiB, so it gets 1 KiB blocks. kryptikd opens every image with dm-verity at --data-block-size=4096, and dm-verity sets the mapped device's logical block size to its data block size. ext4 cannot set a block size below the device's logical block size, so the mount fails with "bad block size 1024", which is EINVAL. The root is far above 512 MiB, so it got 4096-byte blocks by default and never showed this. Any image under 512 MiB has the same flaw.

Fix.

• make_ext4 passes -b 4096. This is a no-op for the root, whose bytes the reproducibility check still compares.
• pack_image refuses an image whose dumpe2fs -h block size isn't 4096, so a later mke2fs default can't bring the flaw back unnoticed.
• software-delivery.md names the block size.

Only stage 06 reads 06-iso.sh, and the image fingerprint doesn't cover it, so round 3's image trees are packed again without a Firefox rebuild.