System update fails "Could not open path to sync"

General Discussions
,
1

System update fails. When config was previously working. With “Could not open path to sync”

We created our own pi image using mender-convert to increase the root disk size. Then created a system artifact using mender-artifact. And successfully deployed it to a new device with the raw pi image from the mender-convert step. This was on 15-Aug-2025, I believe that the mender-update version was 5.0.1.

But now it is not working. I am trying to deploy the same system artifact to a new device with the raw pi image mender-update version 5.0.3 (installed using the copy paste commands given in the ‘connect new device’ tab on the devices dashboard) I get this log output. looks like the path is uninitialized.

“timestamp”:“2025-11-11T14:27:28.877306Z”,“level”:“info”,“message”:“Running Mender client 5.0.3”}
{“timestamp”:“2025-11-11T14:27:28.877617Z”,“level”:“info”,“message”:“Deployment with ID cea1e339-2f95-4484-a75c-a1f073092312 started.”}
{“timestamp”:“2025-11-11T14:27:28.878769Z”,“level”:“info”,“message”:“Sending status update to server”}
{“timestamp”:“2025-11-11T14:27:29.913904Z”,“level”:“info”,“message”:“Installing artifact…”}
{“timestamp”:“2025-11-11T14:27:29.923150Z”,“level”:“error”,“message”:“No such file or directory: Could not open path to sync: ߠ\n^B^@^@^@^@/mender/modules/v3/payloads/0000/tree/version”}
{“timestamp”:“2025-11-11T14:27:29.923740Z”,“level”:“error”,“message”:"Operation canceled: GET https://c271964d41749feb10da762816c952ee.r2.cloudflarestorage.com/mender-artifact-storage-prod-h>
{“timestamp”:“2025-11-11T14:27:29.944763Z”,“level”:“info”,“message”:“Sending status update to server”}
{“timestamp”:“2025-11-11T14:27:30.688438Z”,“level”:“error”,“message”:"Could not send deployment status: Bad response error: Got unexpected response 400 from logs API: invalid character '\x0>
{“timestamp”:“2025-11-11T14:27:30.688629Z”,“level”:“info”,“message”:“Retrying status update after 60 seconds”}
{“timestamp”:“2025-11-11T14:28:30.688825Z”,“level”:“info”,“message”:“Sending status update to server”}

Repeated lines….

{“timestamp”:“2025-11-11T15:03:46.859720Z”,“level”:“error”,“message”:"Could not send deployment status: Bad response error: Got unexpected response 400 from logs API: invalid character '\x0>
{“timestamp”:“2025-11-11T15:03:46.859934Z”,“level”:“error”,“message”:“Giving up on sending status updates to server: Tried maximum number of times: Exponential backoff”}
{“timestamp”:“2025-11-11T15:03:46.863945Z”,“level”:“info”,“message”:“Deployment with ID cea1e339-2f95-4484-a75c-a1f073092312 finished with status: Failure”}

2

Hi @paul.m,

While I have no obvious solution - what happens if you install a really simple artifact, possibly just a file? You can create one on the fly on Hosted Mender, just upload a text file instead of an artifact, and it will guide you through the creation of a simple file artifact which you can deploy right afterwards.

Greetz,
Josef

3

Hi Josef,

Thank you for your response.

I tried this, and I get the same error message {“timestamp”:“2025-11-11T14:27:29.923150Z”,“level”:“error”,“message”:“No such file or directory: Could not open path to sync: ߠ\n^B^@^@^@^@/mender/modules/v3/payloads/0000/tree/version”}

Best regards,

Paul

4

Hi @paul.m,

Is this a board you have at hand? Respectively, is only that one affected, or multiple ones? What happens if you rebuild the image?

Greetz,
Josef

5

Hi Josef,

I have another device that is working, it has the same hardware, root filesystem has same checksum (as shown in the software tab on mender hub). The only difference that I can see in the inventory is that the one that is working is running mender client version 5.0.1 and the one that is not is running 5.0.3. Do you know the best way to downgrade to 5.0.1?

In the mean time I will try from scratch with new hardware.

Best regards,

Paul

6

Hi Josef,

I have tried again with new hardware (new rpi and SD card), installing the same image, then setting up mender client by copy pasting the commands given through hosted mender, then deploying a hello world text file as you suggested. And I get the same issue, but with a different string of random characters. So it does not appear to be hardware related.

level":“error”,“message”:“No such file or directory: Could not open path to sync: ���^A^@^@^@^@/mender/modules/v3/payloads/0000/tree/version”}

Best Regards,

Paul

7

Hi @paul.m,

Something is really weird here, and it’s the only report that I know about so far. :frowning:
You can try to downgrade by specifically setting MENDER_CLIENT_VERSION, as seen here: mender-convert/configs/mender_convert_config at 25ea12e7663eb75a4cf783b18c202585138cb86b · mendersoftware/mender-convert · GitHub

Greetz,
Josef

8

Hi Josef,

I have it working now.

I flashed another SD card with the same image, then changed the /etc/mender/mender.conf to add the hosted mender server and the tenant token. Rebooted and accepted the request. Now I can deploy again. So it seems that the ‘connect new device‘ script to setup the latest mender client was the issue after all. I will create a new image with mender convert that has the tenant token and serverURL built in so that I don’t have to keep copy pasting it in.

Thank you.

Best regards,

Paul

9

Hi @paul.m,

Glad to hear! I’ll check back with the devs if there might be a problem with the copy-paste instructions in onboarding. But great that you can proceed!

Greetz,
Josef

10

Hi @paul.m ,

Good that you found a solution.

However I still suspect another issue. These strange path prefixes like:

ߠ\n^B^@^@^@^@/mender

makes me suspect an old issue that we had with armhf packages. Are you using 32 bit based OS image from Raspberry Pi OS?

We don’t support these anymore with the new releases, starting from mender-update 5.0.2.

Maybe I am off, but I just wanted to rule this out.

Lluís

11

Hi Lluís,

OK, thank you for this.

Yes we based the Mender converted image from the example raspberry pi 4 image from the mender docs website: Prepare a Raspberry Pi device | Mender documentation

Which was 32bit raspios bookworm armhf lite.

So will there be an issue if we continue to use this OS with the mender-client 5.0.1? Will mender-client 5.0.1 continue to work for deployments going forward?

Would there be any issue deploying a 64bit system update with mender client 5.0.3 to a device that is running 32bit OS with Mender client 5.0.1?

Paul

12

Oh, thanks.

So this really is like that, that starting from mender-update 5.0.2 only 64 bit OS is supported??

Because I’m on 32 bit raspberry pi, and running mender-update 5.0.3 and command

mender-update install myupdate.mender

results in

record_id=1 severity=error time="2026-Jan-08 11:45:33.337012" name="Global" msg="No such file or directory: Could not open path to sync: \x08��\x01\x00\x00\x00\x00/mender/modules/v3/payloads/0000/tree/current_device_type" 
Streaming failed.
System not modified.
Could not fulfill request: No such file or directory: Could not open path to sync: \x08��\x01\x00\x00\x00\x00/mender/modules/v3/payloads/0000/tree/current_device_type

So is the problem really the mender-update 5.0.3? Do I need to change to mender-update 5.0.1?

By the way: In the release notes of 5.0.2, I can see nothing that suggests that 32 bit OS support has been dropped: Mender Client | Mender documentation

Rasberry pi 32-bit OS bullseye fails to boot (image via mender-convert)
13

If I set
MENDER_CLIENT_VERSION=5.0.1 in the config

then

2026-01-08 13:37:28 [FATAL] [mender-convert-modify] Cannot choose exact version for package mender-client4 5.0.1 from the APT repository

This is because in

I cannot find
mender-client4_5.0.1-1+debian+bullseye_armhf.deb (for 32 bit OS)

Why is that missing?

I see here that you’ve migrated from
old = https://downloads.mender.io/repos/debian/pool/main/m/mender-client4/ to
new = https://downloads.mender.io/repos/device-components/pool/main/m/mender-client4/

Well in old I can still find mender-client4_5.0.1-1+debian+bullseye_armhf.deb

Please can you make mender-client4_5.0.1-1+debian+bullseye_armhf.deb available in new repo. Thanks

In the meantime a hack to handle it is to set the following in the config, to use the old repo

MENDER_CLIENT_VERSION=5.0.1
MENDER_STORAGE_URL="https://downloads.mender.io"
#   old_repo = https://downloads.mender.io/repos/debian/pool/main/m/
#   new_repo = https://downloads.mender.io/repos/device-components/pool/main/m/
#   currently stay on old_repo, since that still has mender-client4_5.0.1-1+debian+bullseye_armhf.deb
MENDER_APT_REPO_URL="${MENDER_STORAGE_URL}/repos/debian"
14

What a mess and frustrating experience this all is!

I read this:

The latest mender-convert also does not support converting 32-bit Raspberry Pi OS images, as the ARMv6 32-bit packages do not exist in the new repositories. (32-bit Raspberry Pi OS images require an older version of mender-convert , and using 64-bit Raspberry Pi OS is recommended.)

from https://mender.io/blog/new-mender-packaging-and-distribution-channels

Well that’s just wrong.
Raspberry Pi 4 does support ARMv7 code.

It’s just the older models (like like Pi 1 or Pi Zero) that don’t support it.

So in theory the armhf ARMv7 binaries in the new repo should work correctly for 32-bit Raspberry Pi OS images. hmmm…

15

mender-update version 5.0.3
runs on my system: raspberry pi 4 with 32-bit raspberry pi os bullseye

mender-update --version reports 5.0.3

sudo mender-update show-artifact shows myim-1.8.8

But

sudo mender-update install ./myim-1.8.9.mender

shows ERROR:

record_id=1 severity=error time="2026-Jan-12 09:41:06.350798" name="Global" msg="No such file or directory: Could not open path to sync: p��/mender/modules/v3/payloads/0000/tree/current_device_type" 
Streaming failed.
System not modified.
Could not fulfill request: No such file or directory: Could not open path to sync: p��/mender/modules/v3/payloads/0000/tree/current_device_type

But /var/lib/mender/modules/v3/payloads/0000/tree/current_device_type does exist on my system and contains raspberrypi4.

What is going on here?

Edit: here are my investigations:

Ok, so probably there really is a problem when using the armv7 version.

Checking your version’s armv7 /usr/bin/mender-update

objdump -f /usr/bin/mender-update shows

/usr/bin/mender-update:     file format elf32-littlearm
architecture: armv7, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0002c10d

readelf -A /usr/bin/mender-update | grep Tag_CPU_arch: shows

  Tag_CPU_arch: v7

If I build on raspberry pi 4 itself, then mender-update works perfectly (i.e. I do not get junk-characters).

I then compare:

objdump -f mender-update-mine-built-on-rpi4 shows

mender-update:     file format elf32-littlearm
architecture: armv6, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0002caac

readelf -A mender-update-mine-built-on-rpi4 | grep Tag_CPU_arch: shows

  Tag_CPU_arch: v6

And readelf -A /lib/arm-linux-gnueabihf/libc.so.6 | grep Tag_CPU_arch: shows

  Tag_CPU_arch: v6