An agent update now waits for the package manager

On the morning of 2026-10-08 a Debian machine at one of our clients was offered agent 0.3.115. The agent stopped its service and ran the package installer, and the installer failed at once: Debian's own unattended upgrades held the package lock.

The agent rolled back cleanly to the version it had. Then the rollout brake read what it saw, one machine in two failed, and halted the client's rollout. The other 52 machines that took 0.3.115 confirmed it. The build was fine.

An update waits its turn

Debian's package manager takes a lock and doesn't queue behind another holder; it fails. So the agent now asks the kernel who holds that lock before it fetches or stops anything.

A held lock is a reason to ask again shortly, the same as a running scan already is, and the server records an offer not yet taken up. No failed install is written. There's no ceiling on that wait, on purpose: a lock held for hours is a wedged package manager, and there's no installing over it.

In the installer itself, a lock taken in the gap between the check and the install is waited out for up to five minutes. After that the install fails with the holder's process id in the report and rolls back as before. The service is stopped by then, so the wait is bounded.

Windows has the same situation under a different name. When the Windows installer reports that another installation is already running, the agent now treats the machine as busy and retries within the same five minutes. Before, it rolled back a machine that was in the middle of Windows Update.

The installer that performs an update is a copy of the running agent, so this protects installs performed by 0.3.116 and later.

A cleared halt stays cleared

The same morning showed a second fault. The halted rollout was resumed by hand that evening, with the reason on record, and halted again ten minutes later on the next update check.

The brake counted every attempt on the target version, with no far edge, so the one machine that had rolled back was one of two all over again. And because a halted rollout offers nothing, that machine couldn't be offered the retry that would have moved its record. There was no way to clear it.

The counts now start at the moment of the resume. What a person judged and cleared isn't counted twice; what happens after they cleared it is judged on its own. One retry that fails is one of one, and that halts.

The device page walks you through itself again

The guided tour of the device page was retired in August. The page has grown since: the Tickets tab, remote control among the actions, "What this is" in the menu.

The tour is back, with those steps rewritten, in English and German. It no longer scrolls each step behind the sticky bars.

Haiku 5.5 in the chat

Claude Haiku 5.5 joined the Claude 5 generation, which thinks before it answers and takes no temperature setting. Choosing it in the chat failed until the request builders learned that.

It works now, priced at list, on the platform key.

Proving the database matches the code

Anyone who runs Wegweiser on their own hardware, and anyone restoring ours from a backup, has had to trust that the database matched the code. Now the schema is documented, generated from the models, with a test that fails when the document falls behind.

A new command, flask schema_verify, reads a database against the models: tables, columns, indexes, the extension the AI search needs, the triggers and the row-level security the migrations install. It reports what it finds. With --repair it creates what's missing and doesn't drop, alter or tighten anything that holds data.

Its first run was against our staging copy of production. It found ten columns from a migration that hadn't been run there, and four indexes that hadn't been created, in under a second. That's what it's for.