# Debian standalone update fails **URL:** \ **Category:** Debian family\ **Created:** [March 11, 2026, 2:51pm UTC](https://hub.mender.io/t/debian-standalone-update-fails/8207 "2026-03-11T14:51:52Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![user706](https://avatars.discourse-cdn.com/v4/letter/u/ba9def/32.png) [@user706](https://hub.mender.io/u/user706)\ **Post date:** [March 11, 2026, 2:51pm UTC](https://hub.mender.io/t/debian-standalone-update-fails/8207/1 "2026-03-11T14:51:53Z")
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 ```auto 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?) ---
**Author:** ![user706](https://avatars.discourse-cdn.com/v4/letter/u/ba9def/32.png) [@user706](https://hub.mender.io/u/user706)\ **Post date:** [March 12, 2026, 1:00pm UTC](https://hub.mender.io/t/debian-standalone-update-fails/8207/2 "2026-03-12T13:00:12Z")
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 ```auto # 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](https://github.com/tttapa/docker-arm-cross-toolchain)) 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 ```auto /usr/local/lib/arm-linux-gnueabihf/libstdc++.so.6 -> libstdc++.so.6.0.33 ``` And I missed the fine-print regarding ABI incompatibility: [link](https://github.com/tttapa/docker-arm-cross-toolchain?tab=readme-ov-file#abi-compatibility) So running `/usr/bin/mender-update` crashed, because it was linking to a ABI-incompatible C++ library, as seen via ```bash 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** ```bash # remove my own ABI-incompatible c++ lib sudo rm /usr/local/lib/arm-linux-gnueabihf/libstdc++.so* sudo ldconfig ``` Now ```bash 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.