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
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.
The boot logic is in https://github.com/snapcore/core-build/blob/master/initramfs/scripts/ubuntu-core-rootfs#L265 – note that there are three variants there. There’s another
fsck for the writable partition in https://github.com/snapcore/core-build/blob/64062103d8f86b0d9988a0639fea27e71aecf55a/initramfs/scripts/ubuntu-core-rootfs#L148
It would be good to make a test that can pass on core16, core18 and perhaps in core20 (CC @cmatsuoka for design considerations).
@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.
@abeato perhaps I misunderstand something. Where’s the source of the initramfs that runs on core (aka core16) and one that runs on core18 systems?
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:
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.
Thanks for pointing this out. This just magnified the significance of actual integration test that is necessary.
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