Does meta-mender modify /etc/fstab?

Hi All!
I’m using the ‘meta-mender’ (dunfell) layer with the yocto and i’m having problem with the resulting /etc/fstab: this is the fstab. It is strange because i ve also included MENDER_FEATURE_DISABLE_append = ‘mender-image-ubi’, but uboot fstab records still appears.

I guess mender-client is the one involved in updating the fstab configuration, thought about starting fresh running bitbake -c cleansstate mender-client, but didn’t resolve the issue.

Where do i start for troubleshooting?

# stock fstab - you probably want to override this with a machine specific one

/dev/root            /                    auto       defaults              1  1
proc                 /proc                proc       defaults              0  0
devpts               /dev/pts             devpts     mode=0620,ptmxmode=0666,gid=5      0  0
tmpfs                /run                 tmpfs      mode=0755,nodev,nosuid,strictatime 0  0
tmpfs                /var/volatile        tmpfs      defaults              0  0

# uncomment this if your device has a SD/MMC/Transflash slot
#/dev/mmcblk0p1       /media/card          auto       defaults,sync,noauto  0  0

# Where the U-Boot environment resides; for devices with SD card support ONLY!
/dev/sda1            /boot/efi            auto       defaults,sync         0  2
/dev/mapper/data     /data                auto       defaults              0  2

Thanks to everyone!

Hi @AlessioDavoli,

from a first glance at I would assume that the fstab is always modified, as the ROOTFS_POSTPROCESS_COMMAND is unconditionally appended.

To verify that assumption and get a starting point for changing, look at bitbake -e your-image, and inspect the evaluation history of the ROOTFS_POSTPROCESS_COMMAND variable. And as this is being applied at the image postprocessing stage, it won’t be affected by anything related to the mender-client recipe.


Hi TheYoctoJester, thanks a lot.
Now i see why mender-client recipe isn’t strictly bound to

This the output of ‘bitbake -e my-image | grep ROOTFS_POSTPROCESS_COMMAND’ :

1369711-persist_to_data; write_package_manifest; license_create_manifest;   ssh_allow_empty_password;  ssh_allow_root_login;  postinst_enable_logging;  rootfs_update_timestamp ;   write_image_test_data ;  set_systemd_default_target; systemd_create_users; empty_var_volatile; mender_update_fstab_file; mender_create_scripts_version_file; sort_passwd; rootfs_reproducible;
1478130-python __anon_58__home_m4ss_sources_poky_meta_classes_rootfs_postcommands_bbclass () {
1478217-def __anon_58__home_m4ss_sources_poky_meta_classes_rootfs_postcommands_bbclass(d):
1478384:    d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 'rootfs_reproducible;')
1843537-python rootfs_command_variables () {
1843574-def rootfs_command_variables(d):

What should i infer from this info? It seems that all commands are inside the ROOTFS_POSTPROCESS_COMMAND and everything is ok.

I guess that all comands inside ROOTFS_POSTPROCESS_COMMAND will have some logs, in fact I see that has bbdebug, where do i see this logs?