Skip to content

support: capture journal tail from before last reboot#738

Open
cyberb wants to merge 3 commits into
masterfrom
support-previous-boot-tail
Open

support: capture journal tail from before last reboot#738
cyberb wants to merge 3 commits into
masterfrom
support-previous-boot-tail

Conversation

@cyberb
Copy link
Copy Markdown
Member

@cyberb cyberb commented May 29, 2026

Why

The debug-email support report (GetLogs) only dumps the current boot's journal (journalctl -n 2000). When the box goes down uncleanly — hard freeze / power-off, e.g. the photoprism OOM livelock on weak ARM (forum 650, forum 654) — there's no trace of what happened in the seconds before it died.

What

Add a previousBootTail() section: journalctl -b -1 -n 100, the last 100 lines of the previous boot. That's where the kernel hung-task / watchdog / OOM lines land right before an unclean reboot. Slotted right after the current-boot dump in GetLogs.

Degrades gracefully to journald's "boot not available" message when storage is volatile.

Verification

  • go build ./support/ + go test ./support/ pass.
  • Checked on borisarm64: journald is persistent (/var/log/journal ships in the image, ~2.8 GB, 6 boots retained), so journalctl -b -1 -n 100 returns real prior-boot data — the section populates. No install-hook change needed.

Out of scope

The persistent journal has no SystemMaxUse cap (pre-existing, ~2.8 GB) — not addressed here.

cyberb added 3 commits May 29, 2026 23:41
GetLogs only dumps the current boot's journal, so an unclean reboot
(hard freeze / power-off, e.g. the photoprism OOM livelock on weak ARM)
leaves no trace of what happened in the seconds before it went down.

Add a 'journalctl -b -1 -n 100' section: the last 100 lines of the
previous boot, which is where the kernel hung-task/watchdog/OOM lines
land right before the box dies. Degrades gracefully to journald's
'boot not available' message when storage is volatile.
The image proxy hardcoded the legacy object path
(apps.syncloud.org/releases/{channel}/images/{app}-128.png). Newly
published apps (e.g. games) are no longer written there, so the lookup
404'd and the UI fell back to the placeholder icon.

The platform already lists apps via local snapd (/v2/find); snapd relays
the store's media[].url. Capture that, and have /rest/proxy/image resolve
the icon URL from snapd by app name, then stream the bytes. The platform
no longer constructs any store/S3 path — it uses the URL snapd provides
and only proxies bytes (browser can't load the http store URL directly
from the https UI, so the fetch stays server-side).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant