As today using meta-mender on dunfell branch (also with master), and with Poky dunfell branch, generate an invalid /etc/fstab file with this two record appended to the end:
This prevents the system from booting because /boot is already mounted on /boot/efi, and the swap doesn’t exist.
The issue was (we think) introduced after this commit https://github.com/mendersoftware/meta-mender/commit/d50215232a1dfed1ba831ded4617c0b145dbc000, building with meta-mender pinnned on this commit works as expected.
The two records of the /etc/fstab file above are not added during the build phase, because we do not find them in the rootfs.
But we find them if we go to inspect the mender artifact with mender cat $image.mender:/etc/fstab so it could be a corner case with Poky (branch:dunfell) during the image creation process.
Just an update on the topic, sorry, you’re right, the issue is not mender related.
I’ve done a quick investigation, and the two lines are appended by poky/scripts/lib/wic/plugins/imager/direct.py when it creates the direct image format.
In the arguments inside the direct wks plugins can be injected the WIC command-line switch --no-fstab-update to suppress fstab update.
The wks options can be adjusted with the BB env-var WIC_CREATE_EXTRA_ARGS like this:
WIC_CREATE_EXTRA_ARGS ?= “–no-fstab-update”
also used in: mender-part-images.bbclass:159
And this fixes the issue, but the real question behind this, is how this can happen sometimes? And why we don’t have figured it out in the past?
This anomaly is present in Zeus as well. Strangely, at least for us, it is intermittent, and cleaning/purging the build environment and building from scratch will usually result in a clean, working image. Why that would be, I dont know.
–no-fstab-update is a great way to work around this, but i would, of course, prefer it be fixed.