- Mender is using mcopy from the mtools package to create the boot partition for Raspberry Pi and UEFI images: https://github.com/mendersoftware/meta-mender/blob/50e8188f6c69d5e16363a37c2bb6e3abf9542bbb/meta-mender-core/classes/mender-bootimg.bbclass#L35
- mtools had a bug until 4.0.20, where it wrote uninitialized bytes into newly created entries: https://svn.savannah.gnu.org/viewvc/mtools/trunk/direntry.c?r1=363&r2=452
- dosfsck from the dosfstools package had another bug until 4.2, where it regarded unexpected bytes in the reserved part of the entry as bad and "corrected" this by removing affected directories: https://github.com/dosfstools/dosfstools/commit/87a8f29785bb605350821f1638a42e6cf3e49ce3
The combination of all 3 renders devices unbootable once dosfsck is used on the boot partition created by an affected mtools version (= created by Yocto Warrior and earlier).
This is also a problem for newer Yocto releases, because the boot partition stays unchanged when upgrading a Warrior device to Zeus or Dunfell.
This problem is especially crucial considering that Mender reenabled automatic filesystem repairs in Zeus and Dunfell during boot: https://github.com/mendersoftware/meta-mender/commit/0552891c504ecacb0d99f4618694c03f5bc08f83
The fixed dosfstools 4.2 version is not even a month old, so it's currently not part of any Yocto version.
I've submitted a patch to upgrade dosfstools in Yocto master: https://lists.openembedded.org/g/openembedded-core/topic/patch_dosfstools_upgrade/80928608
However, it's questionable whether that patch will be backported to any Yocto release.
As this could potentially brick a lot of production devices, I hope that Mender can either ship the fixed dosfstools version itself via meta-mender or otherwise ensure that the fixed version 4.2 is part of the build.