# Issue on Dunfell (/etc/fstab invalid entry) - fail to boot **URL:** \ **Category:** General Discussions\ **Tags:** yocto, x86-grub\ **Created:** [December 10, 2020, 8:51pm UTC](https://hub.mender.io/t/issue-on-dunfell-etc-fstab-invalid-entry-fail-to-boot/2972 "2020-12-10T20:51:29Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![malveo](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/malveo/32/704_2.png) [@malveo](https://hub.mender.io/u/malveo)\ **Post date:** [December 10, 2020, 8:51pm UTC](https://hub.mender.io/t/issue-on-dunfell-etc-fstab-invalid-entry-fail-to-boot/2972/1 "2020-12-10T20:51:29Z")
Hello Everyone, 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: ```auto UUID=2889-63DA /boot vfat defaults 0 0 UUID=f21a75af-a867-42a3-842c-61fccc05ab5d swap swap defaults 0 0 ``` 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. Best, Mauro ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [December 11, 2020, 7:31am UTC](https://hub.mender.io/t/issue-on-dunfell-etc-fstab-invalid-entry-fail-to-boot/2972/2 "2020-12-11T07:31:41Z")
Hi @malveo, We have seen other reports of this e.g [/etc/fstab will sometimes filled with UUID-Entries (swap and boot) and will destroy upgrade/install](https://hub.mender.io/t/etc-fstab-will-sometimes-filled-with-uuid-entries-swap-and-boot-and-will-destroy-upgrade-install/2515/4). Root cause is still unclear, as this is not something that is added by meta-mender. But it is becoming a pattern, that might be worth investigating closer. ---
**Author:** ![malveo](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/malveo/32/704_2.png) [@malveo](https://hub.mender.io/u/malveo)\ **Post date:** [December 11, 2020, 11:36am UTC](https://hub.mender.io/t/issue-on-dunfell-etc-fstab-invalid-entry-fail-to-boot/2972/3 "2020-12-11T11:36:02Z")
Hi @mirzak , 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? Best, Mauro ---
**Author:** ![SuicidalLabRat](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/suicidallabrat/32/311_2.png) [@SuicidalLabRat](https://hub.mender.io/u/SuicidalLabRat)\ **Post date:** [December 16, 2020, 8:00pm UTC](https://hub.mender.io/t/issue-on-dunfell-etc-fstab-invalid-entry-fail-to-boot/2972/4 "2020-12-16T20:00:40Z")
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.