Incomprehensible problem on FX30

Hello,

I’ve built a Yocto (swi-mdm9x15) image based on the attached bb file.

I made several modifications in my application and suddendly saw that useradd command didn’t work anymore when flashing the image.
More precisely, users were added to /etc/shadow but not in /etc/passwd not in /etc/group. I tried to reset it, flash a swi-mdm9x15 stock image, reflash my image … Nothing!

Well, as I had a newly bought FX30, I tried to flash my image on it and everything was working, notably I found my added users. … For some days!

Because today I face the same problem as with my first FX30: flashing the image doesn’t “completely” add the users, I find them in /etc/shadow but not in /etc/passwd nor in /etc/group!!

Can anyone explain what happens and how to get it working back ??

I tried a Factory Reset with the button, erase the user partition with FDT. Nothing!

Alain :cry:
blackbox.bb.txt (4.1 KB)

Hi Alain,
Sounds like the files that are not updating are located in the “overlay”. Once a file is manually modified, a copy of it is stored in the overlay so it is not overwritten with a firmware update.

You can check to see if your modified files are located here:

/mnt/flash/ufs/etc

BR,
Chris

Hello Chris,

The files in /mnt/flash/ufs/etc are the same as in /etc…

Alain

Hi Alain,
That’s correct, the files will be the same.

Try this:

cd /mnt/flash/ufs/etc
rm /etc/password
rm /etc/group
rm /etc/shadow
reboot

What this does is that files that have been manually modified and copied to the overlay are now deleted. Note, you’ll lose any manual changes you’ve done to the files, so you might want to make a backup copy if you need them. After the reboot, the files will be reverted back identically to the original contents in the image.

BR,
Chris

@cchenry,
Wow, you solved my problem.

But there is a question anyway. I got it after several image flashing, I never tried to change /etc/passwd, nor execute useradd before I noticed it doesn’t work anymore.

So I’m really afraid to install some FX30 in our customer plants and see one day that the problem comes back again.

What could produce this problem please ?
Is it caused by the method used in our bb file?

DESCRIPTION = "Startup scripts"

    LICENSE = "MIT & BSD-3-Clause & BSD-2-Clause & PD"
    LIC_FILES_CHKSUM = "file://../LICENSE;md5=eef71d57c191bf0563e2407afc838f99"

    require blackbox.inc

    PR = "r0"
    RPROVIDES_${PN}="blackbox"

    SRC_URI = "         \
       file://LICENSE \
       file://config.json \
       file:///home/me/VisionBox/latest.zip \
       "
    inherit useradd

    USERADD_PACKAGES = "${PN}"
    GROUPADD_PACKAGES = "${PN}"
    GROUPADD_PARAM_${PN} = "configuration"
    USERADD_PARAM_${PN} = "-d /tmp -G configuration blackbox; -m -d /tmp -s /usr/sbin/generate_config.sh -G configuration -p wtmoOHy.mTsUk technicien"

    do_compile() {
        make -C .. clean 
        make -C .. CC='arm-poky-linux-gnueabi-gcc' AR='arm-poky-linux-gnueabi-ar'
    }

    do_install() {
        install -d ${D}${sysconfdir}/init.d
        install -d ${D}${sysconfdir}/rcS.d
        install -d ${D}${sysconfdir}/rc1.d
        install -d ${D}${sysconfdir}/rc2.d
        install -d ${D}${sysconfdir}/rc3.d
        install -d ${D}${sysconfdir}/rc4.d
        install -d ${D}${sysconfdir}/rc5.d
        install -d ${D}${sbindir}

        install -m 0544 ${WORKDIR}/scripts/initscript.sh        			${D}${sysconfdir}/init.d/blackbox
        install  -m 0700 ${WORKDIR}/blackbox_client        	${D}${sbindir}/blackbox_client
        install -o technicien -m 0500 ${WORKDIR}/scripts/generate_config.sh   	${D}${sbindir}/
        install -o blackbox -g configuration -m 0660 ${WORKDIR}/config.json		${D}${sysconfdir}/
        install -d ${D}${sysconfdir}/dnsmasq.d

        echo "/usr/sbin/generate_config.sh" >> ${D}${sysconfdir}/shells
        echo "/bin/sh" >> ${D}${sysconfdir}/shells

        ln -sf ../init.d/blackbox        ${D}${sysconfdir}/rcS.d/S90blackbox
        ln -sf ../init.d/blackbox        ${D}${sysconfdir}/rc1.d/K90run-script
        ln -sf ../init.d/blackbox        ${D}${sysconfdir}/rc2.d/K90run-script
        ln -sf ../init.d/blackbox        ${D}${sysconfdir}/rc3.d/K90run-script
        ln -sf ../init.d/blackbox        ${D}${sysconfdir}/rc4.d/K90run-script
        ln -sf ../init.d/ablackbox        ${D}${sysconfdir}/rc5.d/S90run-script
        ln -sf /etc/init.d/snmpd	     ${D}${sysconfdir}/rcS.d/S90snmpd
        echo "blackbox ALL = NOPASSWD: /sbin/reboot" >> ${D}${sysconfdir}/sudoers

        echo "blackbox ALL = NOPASSWD: /mnt/legato/system/bin/fwupdate" >> ${D}${sysconfdir}/sudoers
    }

Hi Alain,
No, I don’t think it’s your recipe. I think the issue is because your scripts create a new user and password for that user. When you execute the associated Linux commands, the files are copied into the overlay since they are “manually” edited (by the OS in this case). It’s no different if you use something like vi to edit the files.
BR,
Chris

Hi Chris,

Unfortunately I don’t know how everything is working exactly.
Do these commands are executed during flash? i.e. on a first boot?
Or during every boot?

Do you mean it’s not possible to do that without problem? But in that case what to do?

I noticed that I can flash several images before getting the problem.

Hi Alain,
Basically, when you flash firmware onto the FX30, default firmware partitions are written with the new kernel, rootfs, etc. If no files are ever modified, the system will use the default files that were written during the fwupdate.

Once a user or a process edits a file, it gets copied to the overlay which is the partition you’re seeing in /mnt/flash/ufs. Files in the overlay are not updated during a firmware update. However, if the new firmware contains changes to the same file, that file is updated only in the firmware partitions, ie, the default files are updated. So now you have a case where the default files are updated, but aren’t used because they were previously copied to the overlay.

If I understand your scripts/application correctly, it sounds like they are creating a user and setting a password. I suspect there’s an issue the /etc/passwd and /etc/group are being incorrectly written to, wiping out previous entries.

BR,
Chris

Hi Chris,

Ok thanks I better understand how it works.
I’m going to see if I can get support from Sierra Wireless to precisely identifying the problem.

Alain