[7.4] Image.status unvollständig

Arnaud · 16. September 2026 um 13:07

Ich habe heute bei uns gesehen, dass die image.status Dateien nicht aktualisiert sind.

Gerade wurde ein Computer per linbo-remote gesynct und gestartet, aber der Eintrag in /var/log/linuxmuster/linbo/{device}_image.status bleibt:

202609100723 applied: data.qcow2 "202608011714"

(nur die Data-Partition, und nicht OS-Partition, normalerweise gibt es noch eine weitere Zeile für noble.qcow2).

Mit der Übersicht auf alle Geräte kann ich feststellen, dass bei allen nur eine Zeile (eine Partition) im image.status auftaucht.

Habe ich irgendwas verpasst ?
(wir haben gerade linbo 7.4.14 am laufen)

Danke und Gruß

Arnaud

Arnaud · 16. September 2026 um 16:32

Hallo zusammen,

Issue erstellt:

github.com/linuxmuster/linuxmuster-linbo7

`<host>_image.status` keeps only the last synced image since 4.3.0-0 — per-image merge removed in 13ff562

ouvert 04:29PM - 16 Sep 26 UTC

kiarn

# `<host>_image.status` keeps only the last synced image since 4.3.0-0 — per-ima…ge merge removed in 13ff562 ## Summary `/var/log/linuxmuster/linbo/<host>_image.status` used to hold **one line per synced image**. Since commit `13ff562` it holds **exactly one**: whichever image was synced last. Every other entry is discarded on each upload. This is not a client-side problem. The client has always uploaded a single-line file; the per-image merge was done on the server, and that is what was removed. ## Expected vs. actual Expected — a real file from one of our hosts, written while the server was still running **4.2.16-0**: ``` 202511162102 applied: jammy.qcow2 "202511091158" 202511190938 applied: data-jammy.qcow2 "202507141657" ``` One line per image, each updated in place: the two entries are three days apart, so this is not a single sync session — the earlier entry survived the later sync. Actual, on 7.4.14, after explicitly syncing both partitions: ``` 202609100723 applied: data.qcow2 "202608011714" ``` The two behaviours were observed on the same server, and `/var/log/dpkg.log` dates the switch exactly: ``` 2025-11-21 20:23:34 upgrade linuxmuster-linbo7:all 4.2.16-0 4.3.29-0 ``` Checked against the tags: `v4.2.16` still contains the per-image merge, `v4.3.29` does not. ## Reproduction ``` linbo-remote -i <host> -c sync:1,sync:2,start:1 ``` Both partitions are synced, so `restore()` runs twice and `log_image_status ... applied` is called twice — two uploads, one line each. Only the second one survives in `<host>_image.status`. ## Affected versions Introduced in **4.3.0-0** (`lmn72-testing`, 19 Sep 2024) by `13ff562` — *"receive hardware info from linbo client (#117)"*. First shipped to `lmn73` with 4.3.3-1, still present in **7.4.14**. The script is unchanged across every `4.3.x` and `7.4.x` tag and on branches `4.3`, `7.4` and `main`; the last version carrying the merge is `v4.2.16`. This is easy to miss on an existing installation: `<host>_image.status` is only rewritten on a successful upload, so hosts that have not synced since the upgrade keep their old, correct multi-line file indefinitely. Ours still had a two-line file from November 2025 for a machine that had not been synced since. ## Root cause Before `13ff562`, `rsync-pre-download.sh` had a dedicated `status)` branch that merged the incoming line into the target file, replacing only the entry for that same image: ```sh # fetch image status from client status) ... if [ -s "$FILE" ]; then if [ -s "$tgt_logfile" ]; then # remove older entry for image image="$(cat "$FILE" | awk '{ print $3 }')" [ -n "$image" ] && sed -i "/$image/d" "$tgt_logfile" fi cat "$FILE" >> "$tgt_logfile" fi rm -f "$FILE" touch "$FILE" ;; ``` `13ff562` folded `status)` into the shared `log|status|gz)` branch, and the merge became a plain copy: ```sh log|status|gz) ... if [ -s "$FILE" ]; then if [ "$EXT" = "log" ]; then cat "$FILE" >> "$targetfile" else cp "$FILE" "$targetfile" # <-- whole file replaced for .status fi rm -f "$FILE" fi ;; ``` Only `.log` still appends; `.status` is overwritten in full. The client is not at fault and needs no change: `log_image_status()` in `usr/share/linbo/shell_functions` writes a **single** line with `echo "$status" | tee "$logfile"` (no `-a`), and `sendlog` uploads and deletes it immediately. One upload = one line. Accumulating them was the server's job. ## Suggested fix Take `status` back out of the shared branch and merge per image again: ```sh if [ -s "$FILE" ]; then case "$EXT" in log) cat "$FILE" >> "$targetfile" ;; status) # keep one line per image: drop the previous entry for this image # before appending the new one image="$(awk '{ print $3 }' "$FILE")" if [ -s "$targetfile" ] && [ -n "$image" ]; then awk -v img="$image" '$3 != img' "$targetfile" > "$targetfile.new" \ && mv "$targetfile.new" "$targetfile" fi cat "$FILE" >> "$targetfile" ;; *) cp "$FILE" "$targetfile" ;; esac rm -f "$FILE" fi ``` **Please do not restore the pre-`13ff562` code verbatim.** Its `sed -i "/$image/d"` used the image name as an unanchored regular expression, so with the common `<os>.qcow2` / `data-<os>.qcow2` naming, syncing the OS image *after* the data image would delete the data line as well (`/jammy.qcow2/` matches inside `data-jammy.qcow2`). The example above compares field 3 exactly, which also removes the regex metacharacter issue with the `.` in `.qcow2`. ## Why this is only being reported now Two independent reasons, and one of them is our own fault. Our server only moved off the 4.2 line on 2025-11-21, so we had never run a release carrying the regression before that date. More importantly, the missing entry was invisible in our own tooling. `linuxmusterTools.linbo.last_sync()` used to test the image name as a **substring of the whole log line** and kept the last match: ```python for line in open(statusfile, 'r').readlines(): if image in line: image_last_sync = line.rstrip().split(' ')[0] ``` With the common `<os>.qcow2` / `data-<os>.qcow2` naming, `jammy.qcow2` matches inside `data-jammy.qcow2`, so the OS image silently inherited the data image's timestamp. That returned **the same value for a complete two-line file and for a truncated one-line file**, which is exactly why the loss went unnoticed for months. Fixed on our side in `linuxmuster-tools` (`c5dbf11`, exact comparison on field 3); the missing entry became visible immediately afterwards, which is what triggered this report. Mentioning it here so the two-year gap between the regression and this issue is not mistaken for the bug being harmless. A separate issue covers two reliability defects in the same upload path that we ran into while investigating. ## How this was verified - `/usr/share/linuxmuster/linbo/rsync-pre-download.sh` from the **installed package**, md5 `4115daef0a95be91e377ec2ab0e783db` — identical to tags 7.4.5 through 7.4.14 and to `main`; `dpkg -V linuxmuster-linbo7` reports no local modification. - `usr/share/linbo/shell_functions` extracted from the **deployed** `/srv/linbo/linbofs64`, confirming `tee` without `-a`. - The removed code recovered with `git show 13ff562^:serverfs/usr/share/linuxmuster/linbo/rsync-pre-download.sh`; the marker `remove older entry for image` is present only between `210b662` (2021) and `13ff562` (2024), and absent from 4.3.33-0, 7.4.5 and 7.4.14. Originally reported at https://ask.linuxmuster.net/t/12376 Thanks Arnaud

Gruß

Arnaud