/usr/bin/mender missing

General Discussions
1

Hi,

I’m building a mender image for raspberry pi, and now all of a sudden it looks like /usr/bin/mender is no longer in the partitions.

Why??

It worked a while back.
I’m using MENDER_CONVERT tag 4.0.1
but in my version had changed this line mender-convert/Dockerfile at 4.0.1 · mendersoftware/mender-convert · GitHub
from ARG MENDER_ARTIFACT_VERSION=master to ARG MENDER_ARTIFACT_VERSION=3.10.0
(it’s massively bad practice to hardmode master – see here)

I called the image creation like this:

MENDER_ARTIFACT_NAME=mine-1 ./mender-convert --disk-image "input/roper-rpi-im\
age.img"  --config ./configs/roper_config --overlay ./rootfs_overlay_roper/

and not like this

MENDER_ARTIFACT_NAME=mine-1 MENDER_CONVERT_VERSION="$(git describe --tags --dirty --exact-match 2> /dev/null || git rev-parse --short HEAD)" ./mender-convert --disk-image "input/roper-rpi-im\
age.img"  --config ./configs/roper_config --overlay ./rootfs_overlay_roper/

I hope that’s no problem.

In any case running this script on the image file that I get via xz -d -k mine-1.img.xz …

#!/usr/bin/env bash

IMAGEFILE=*.img # mine-1.img

MOUNTDIR_P2=/tmp/mountdir_p2
MOUNTDIR_P3=/tmp/mountdir_p3
mkdir -p $MOUNTDIR_P2
mkdir -p $MOUNTDIR_P3

LOOP_VAR=$(sudo losetup -fP --show $IMAGEFILE)



FLAGS="" #FLAGS="-o ro"

sudo mount `#-o users` $FLAGS ${LOOP_VAR}p3 $MOUNTDIR_P3
sudo mount `#-o users` $FLAGS ${LOOP_VAR}p2 $MOUNTDIR_P2
#sudo mount `#-o users` $FLAGS ${LOOP_VAR}p1 $MOUNTDIR_P2/boot

ls $MOUNTDIR_P2/usr/bin/mender
ls $MOUNTDIR_P3/usr/bin/mender
read -p "hit enter to unmount"

#sudo umount $MOUNTDIR_P2/boot
sudo umount $MOUNTDIR_P2
sudo umount $MOUNTDIR_P3

sudo losetup -d $LOOP_VAR

results in

ls: cannot access '/tmp/mountdir_p2/usr/bin/mender': No such file or directory
ls: cannot access '/tmp/mountdir_p3/usr/bin/mender': No such file or directory

… shows that /usr/bin/mender is missing.

Any ideas??

2

ok, if I simply rerun the build, it passes and works and has /usr/bin/mender

I think your scripts don’t catch the case where the download of mender-client_3.5.2-1+debian+bullseye_armhf.deb fails. (?) Is that possible?

So I think the server might have been down, and thus the deb file was not downloaded; but it was not caught by the script. That’s what I think happended. (?)

3

To catch this, if it ever happens again, I’m now using a custom hook to check for the existence of /usr/bin/mender:

config/custom_config

with

# https://docs.mender.io/operating-system-updates-debian-family/convert-a-mender-debian-image/customization#list-based-hooks

check_for_usr_bin_mender() {
    # # uncomment the following 2 lines, to check successful fail
    #ls work/rootfs/usr/bin/mender
    #rm work/rootfs/usr/bin/mender
    if [ ! -e work/rootfs/usr/bin/mender ]; then
        >&2 echo "Error: /usr/bin/mender does not exist"
        exit 1
    fi
}

PLATFORM_MODIFY_HOOKS+=(check_for_usr_bin_mender)
4

I had a similar issue.

Mender-client 4.0.0 was released recently. It was rewritten from scratch with C++. Hence, the integration way was changed and there are no more single /usr/bin/mender - there are multiple different binaries for different purposes.

Moreover, mender-convert is not ready to integrate client version 4.0.0 yet - in my case, mender-convert fails to install mender-client if it is set to 4.0.0 or latest. This impacts all mender-convert versions that use mender-client integration set to latest, because mender-client 4.0.0 is released. This issue was rectified in mender-convert version 4.1.1. Otherwise, if updating mender-convert is a burden - ensure to specify 3.5.2 as the mender-client version for mender-convert within your *.conf file(s):

# Change back to "latest" when mender-convert
# will be supporting client v4.0.0 integration
MENDER_CLIENT_VERSION="3.5.2"

Here is a diff between mender-convert v4.1.0 and v4.1.1