# /usr/bin/mender missing

**URL:** <https://hub.mender.io/t/usr-bin-mender-missing/6523>\
**Category:** General Discussions\
**Created:** [January 30, 2024, 4:22pm UTC](https://hub.mender.io/t/usr-bin-mender-missing/6523 "2024-01-30T16:22:44Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![user706](https://avatars.discourse-cdn.com/v4/letter/u/ba9def/32.png) [@user706](https://hub.mender.io/u/user706)\
**Post date:** [January 30, 2024, 4:22pm UTC](https://hub.mender.io/t/usr-bin-mender-missing/6523/1 "2024-01-30T16:22:44Z")

</div>

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](https://github.com/mendersoftware/mender-convert/blob/4.0.1/Dockerfile#L14)  
from `ARG MENDER_ARTIFACT_VERSION=master` to `ARG MENDER_ARTIFACT_VERSION=3.10.0`  
(it’s massively bad practice to hardmode `master` – see [here](https://hub.mender.io/t/mender-convert-tag-4-0-1-mender-artifact-version-master/5882))

I called the image creation like this:

```bash
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

```bash
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` …

```bash
#!/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

```auto
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??

---

<div class="post-metadata">

**Author:** ![user706](https://avatars.discourse-cdn.com/v4/letter/u/ba9def/32.png) [@user706](https://hub.mender.io/u/user706)\
**Post date:** [January 31, 2024, 10:31am UTC](https://hub.mender.io/t/usr-bin-mender-missing/6523/2 "2024-01-31T10:31:34Z")

</div>

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. (?)

---

<div class="post-metadata">

**Author:** ![user706](https://avatars.discourse-cdn.com/v4/letter/u/ba9def/32.png) [@user706](https://hub.mender.io/u/user706)\
**Post date:** [January 31, 2024, 1:23pm UTC](https://hub.mender.io/t/usr-bin-mender-missing/6523/3 "2024-01-31T13:23:57Z")

</div>

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

```bash
# 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)

```

---

<div class="post-metadata">

**Author:** ![dmitrijsan](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dmitrijsan/32/1942_2.png) [@dmitrijsan](https://hub.mender.io/u/dmitrijsan)\
**Post date:** [February 1, 2024, 1:28pm UTC](https://hub.mender.io/t/usr-bin-mender-missing/6523/4 "2024-02-01T13:28:11Z")

</div>

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](https://docs.mender.io/release-information/release-notes-changelog/mender-convert#mender-convert-4-1-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):

```auto
# 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](https://github.com/mendersoftware/mender-convert/compare/4.1.0...4.1.1) between `mender-convert` v4.1.0 and v4.1.1