We need to write a test for core systems, that the boot partition is fscked. During a debugging session it was noticed that there’s no fsck.vfat seeded in core18 boot snap. This was fixed by https://github.com/snapcore/core18/pull/139
The test should corrupt the boot FAT partition (even by explicitly setting the mounted flag) and then checking this flag being cleaned up by the boot logic after reboot.
@zyga-snapd those are initramfs scripts, and afaik core18 does not include initramfs. Anyway, I thinks it is a good idea to include dosfstools, just not sure why are you pointing to those scripts.
That is not really what I am pointing out. What I am saying is that, when core16 is built, an initramfs is created and included in the snap, concretely: /snap/core/current/boot/initrd.img-core.
When core18 is built, no initramfs is created, or at least no initramfs is included in the snap. So adding these tools to the build won’t make any difference to the non-built anyway initramfs. Although I think it is nice to have them into the core18 snap.
Note here that snapcraft’s kernel plugin takes the initramfs from core16 always - this is problematic and a known issue.
note that fsck runs in two different locations here … one is, as @abeato said, happening inside the initrd before /boot is mounted, the second is an fsck that systemd forces upon us when the mount unit is mounted later in the boot process … we could perhaps avoid the systemd bit (since it is superfluous) by setting the “fs_passno” field in fstab from 2 to 0 during fstab generation:
$ grep boot /etc/fstab
/dev/mmcblk0p1 /boot/uboot auto defaults 0 2