Debian standalone update fails

We have a device which fails with update.

This is strange since all other devices worked nicely.

Here’s what happens:

Command
sudo mender-update -l trace install /data/sw-1.9.1.mender

results in

record_id=1 severity=trace time="2026-Mar-11 15:42:55.989251" name="Global" msg="Entering state N6mender6update10standalone20PrepareDownloadStateE" 
record_id=2 severity=trace time="2026-Mar-11 15:42:55.990320" name="Global" msg="Entry name: version" 
record_id=3 severity=trace time="2026-Mar-11 15:42:55.990513" name="Global" msg="Parsing Version" 
record_id=4 severity=trace time="2026-Mar-11 15:42:55.990845" name="Global" msg="Parsing the Manifest" 
record_id=5 severity=trace time="2026-Mar-11 15:42:55.990963" name="Global" msg="Entry name: manifest" 
record_id=6 severity=trace time="2026-Mar-11 15:42:55.993069" name="Global" msg="Entry name: header.tar.xz" 
record_id=7 severity=trace time="2026-Mar-11 15:42:55.993184" name="Global" msg="Check version integrity" 
record_id=8 severity=trace time="2026-Mar-11 15:42:55.993290" name="Global" msg="Parsing the Header" 
record_id=9 severity=trace time="2026-Mar-11 15:42:55.993855" name="Global" msg="Entry name: header-info" 
record_id=10 severity=trace time="2026-Mar-11 15:42:55.993950" name="Global" msg="StringToType: header-info" 
record_id=11 severity=trace time="2026-Mar-11 15:42:55.994023" name="Global" msg="Parse(header-info)" 
record_id=12 severity=trace time="2026-Mar-11 15:42:55.994288" name="Global" msg="Parsing the payloads" 
record_id=13 severity=trace time="2026-Mar-11 15:42:55.994404" name="Global" msg="Parsing the header-info artifact_provides" 
record_id=14 severity=trace time="2026-Mar-11 15:42:55.994489" name="Global" msg="Parsing the header-info provides:artifact_name" 
record_id=15 severity=trace time="2026-Mar-11 15:42:55.994561" name="Global" msg="Parsing the header-info provides:artifact_group (if any)" 
record_id=16 severity=trace time="2026-Mar-11 15:42:55.994635" name="Global" msg="Parsing the header-info depends:artifact_depends (if any)" 
record_id=17 severity=trace time="2026-Mar-11 15:42:55.994782" name="Global" msg="Entry name: headers/0000/type-info" 
record_id=18 severity=trace time="2026-Mar-11 15:42:55.994859" name="Global" msg="StringToType: headers/0000/type-info" 
record_id=19 severity=trace time="2026-Mar-11 15:42:55.995150" name="Global" msg="Parsing the sub-header ..." 
record_id=20 severity=trace time="2026-Mar-11 15:42:55.995231" name="Global" msg="Parse(type-info)..." 
record_id=21 severity=trace time="2026-Mar-11 15:42:55.995390" name="Global" msg="type-info: Parsing the payload type" 
record_id=22 severity=trace time="2026-Mar-11 15:42:55.995469" name="Global" msg="type-info: Parsing the artifact_provides" 
record_id=23 severity=trace time="2026-Mar-11 15:42:55.995570" name="Global" msg="type-info: Parsing the artifact_depends" 
record_id=24 severity=trace time="2026-Mar-11 15:42:55.995646" name="Global" msg="No artifact_depends found in type-info" 
record_id=25 severity=trace time="2026-Mar-11 15:42:55.995710" name="Global" msg="type-info: Parsing the clears_artifact_provides" 
record_id=26 severity=trace time="2026-Mar-11 15:42:55.995800" name="Global" msg="Finished parsing the type-info.." 
record_id=27 severity=debug time="2026-Mar-11 15:42:55.995892" name="Global" msg="Setting the type-info in payload nr 0 to rootfs-image" 
record_id=28 severity=trace time="2026-Mar-11 15:42:55.995987" name="Global" msg="Entry name: headers/0000/meta-data" 
record_id=29 severity=trace time="2026-Mar-11 15:42:55.996053" name="Global" msg="StringToType: headers/0000/meta-data" 
record_id=30 severity=trace time="2026-Mar-11 15:42:55.996510" name="Global" msg="sub-header: looking for meta-data" 
record_id=31 severity=trace time="2026-Mar-11 15:42:55.996578" name="Global" msg="Parsing the header meta-data" 
record_id=32 severity=trace time="2026-Mar-11 15:42:55.996946" name="Global" msg="Received json load error: Failed to parse JSON from stream: Empty input encountered" 
record_id=33 severity=trace time="2026-Mar-11 15:42:55.997033" name="Global" msg="Received an empty Json body. Not treating this as an error" 
record_id=34 severity=trace time="2026-Mar-11 15:42:55.997138" name="Global" msg="sub-header: parsed the meta-data" 
record_id=35 severity=trace time="2026-Mar-11 15:42:56.000386" name="Global" msg="Entering state N6mender6update10standalone9ExitStateE" 
record_id=36 severity=error time="2026-Mar-11 15:42:56.000569" name="Global" msg="No such file or directory: Could not open path to sync: Ä/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: Ä/mender/modules/v3/payloads/0000/tree/current_device_type

I’m using mender-update version 5.0.1 on raspberry by 4 with 32 bit OS.

Strange is the corrupt character above Ä. Each time I try mender-update install, I get a different corrupt character.

What could this be?

Is this corrupt?
(Any commands to repair it?)

Ah, the /usr/bin/mender-update program was linking to a custom (ABI-incompatible) c++ library that I loaded onto the raspberry pi.

So it is my mistake:
I copied

# libstdc++.so.6.0.33
/opt/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/sysroot/lib/libstdc++.so.6.0.33

from the armv8-rpi3-linux-gnueabihf toolchain from here (GitHub - tttapa/docker-arm-cross-toolchain: Modern GCC cross-compilation toolchains for Raspberry Pi · GitHub) to the raspberry pi’s path
/usr/local/lib/arm-linux-gnueabihf/libstdc++.so.6.0.33 and then gave the following command on raspberry pi sudo ldconfig which created the symlink

/usr/local/lib/arm-linux-gnueabihf/libstdc++.so.6 -> libstdc++.so.6.0.33

And I missed the fine-print regarding ABI incompatibility: link

So running
/usr/bin/mender-update
crashed, because it was linking to a ABI-incompatible C++ library, as seen via

ldd /usr/bin/mender-update
#showed
# libstdc++.so.6 => /usr/local/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb689d000)
#                                                      ^^^^^^^^^^^^^^
#                                          my ABI-incompatible C++ library
#                                          under /usr/local/lib/...

So the solution was

# remove my own ABI-incompatible c++ lib
sudo rm /usr/local/lib/arm-linux-gnueabihf/libstdc++.so* 
sudo ldconfig

Now

ldd /usr/bin/mender-update
#showed
# libstdc++.so.6 => /lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb68a0000)
#                                            ^^^^^^^^^^^^^^
#                                          systems own correct lib

And now /usr/bin/mender-update no longer crashes.

If I want to use a foreign toolchain on this 32-bit system, I should rather have chosen armv6-rpi-linux-gnueabihf (instead of armv8-rpi3-linux-gnueabihf), since that one is ABI-compatible with raspberry pi OS 32-bit system.