On this page
Updates and diagnostics
Check does not always mean inspect-only
In Settings → Updates, distinguish the running version, available version and installed version awaiting relaunch. The released-build checker runs hourly; SAFE skips scheduled checks and refuses a manual check. A build without a valid release version does not arm checking.
Sources: Checker lifecycle
Check now can install an update when automatic installation is enabled and the installation allows replacement. Saving the automatic-install setting and then checking is consequential, not a preview. Downloaded release archives must pass signature/hash, version/platform/architecture and revocation checks. An announced release is not evidence that it has been verified or installed.
Sources: Archive verification; Signed release binding
For a self-replaceable installation, installed — relaunch to run it means disk installation, not that the current process changed. Relaunch now requests a restart. Where staging is refused, use the displayed installation-specific route; do not force permissions to make self-update work. A package-owned Linux installation may offer a downloaded, signature-verified package and an exact installation command. That package-manager action can restart a service. Mobile builds only report availability.
Sources: Update controls and states; Package preparation
Before an intentional upgrade, retain recovery material and record the current build, model/provider and baseline behavior. For an updater-managed replacement, a later start can attempt binary rollback if an earlier boot attempt never reached the boot-success marker and the retained backup/state and replacement permissions still permit it. Reaching the marker normally retires update recovery state; later crashes or behavioral regressions are not this trigger. Binary rollback is not a promise to reverse every data change or external effect. A restored snapshot is not a frozen behavioral baseline. Compare deliberate before/after probes rather than expecting identical answers.
Sources: Update boot recovery decision; Binary rollback boundaries
Diagnose before changing more state
Record the exact error, timestamp, running build, OS/architecture and phase: download, verification, disk installation, relaunch or startup. Preserve uncertainty: a lost connection is not proof that an action failed. The backup interface explicitly says completion is unknown after connection loss and does not automatically retry. Review current state before repeating a consequential request.
Sources: Backup connection loss
Settings → Logs lists retained files and a tail view. Its directory/retention settings apply on restart; an empty configured directory disables file logging. The inspected backend returns at most 400 tail lines, not the entire diagnostic history. Do not infer that an absent tail entry proves no event occurred.
Sources: Log settings and viewer; Tail boundary
Before sharing, make a separate sanitized excerpt. Remove credentials, passphrases, private keys, personal conversations, endpoints/account identifiers and sensitive paths. Ordinary logs are not certified secret-free by this review. Keep the original privately for investigation; report what was removed.
Advanced log taps capture raw payloads, not merely status messages. Do not enable them as a routine first step. A tap without an expiry records indefinitely until stopped; stopping does not erase captures, and an exchange already underway can finish capture. See the operations reference for the distinction between inspecting logging and changing it.
Sources: Tap consequences
Open validation: install-type/platform replay, real UI captures, failure recovery, accessibility and unfamiliar-reader trials. Nothing here certifies an update or restore pass.
Boot-marker boundary: healthy-boot settlement.