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 mender-setup-image.inc 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.
Greetz,
Josef
Hi TheYoctoJester, thanks a lot.
Now i see why mender-client recipe isn’t strictly bound to mender-setup-image.inc.
This the output of ‘bitbake -e my-image | grep ROOTFS_POSTPROCESS_COMMAND’ :
1369680: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;
--
1478129-
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):
1478300: d.appendVar('ROOTFS_POSTPROCESS_COMMAND', '${SORT_PASSWD_POSTPROCESS_COMMAND}')
1478384: d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 'rootfs_reproducible;')
1478454-}
1478456-
1478457-
--
1843536-
1843537-python rootfs_command_variables () {
1843574-def rootfs_command_variables(d):
1843607: return ['ROOTFS_POSTPROCESS_COMMAND','ROOTFS_PREPROCESS_COMMAND','ROOTFS_POSTINSTALL_COMMAND','ROOTFS_POSTUNINSTALL_COMMAND','OPKG_PREPROCESS_COMMANDS','OPKG_POSTPROCESS_COMMANDS','IMAGE_POSTPROCESS_COMMAND',
1843820- 'IMAGE_PREPROCESS_COMMAND','RPM_PREPROCESS_COMMANDS','RPM_POSTPROCESS_COMMANDS','DEB_PREPROCESS_COMMANDS','DEB_POSTPROCESS_COMMANDS']
1843966-}
1843968-
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 mender-setup-image.inc has bbdebug, where do i see this logs?