| docs

Appearance

System Updates ​

The System Updates page lets you check your AdminBolt version and install available updates.

System Updates Overview

Overview ​

URL: /admin/system-updates

The page header reads: "Manage and monitor your AdminBolt installation." It checks for updates automatically when opened.

Version Information ​

  • Current Version - The version currently installed on your system.
  • Latest Version - The latest available version.

When an update is available, the release notes are shown inline under What's New. A System Information panel lists the Product, Environment, and Status.

States ​

  • Up to date - no action is needed; a View changelog link opens the Changelog.
  • Update available - the release notes appear inline and an Install update button applies the update.
  • Ahead of latest - shown when the installed version is newer than the latest available version.

Actions ​

  • Check for updates - re-check for a newer panel version.
  • Install update - download and install the available update (shown only when an update is available).
  • View changelog - open the changelog (shown when the panel is already up to date).

If an update fails ​

The page shows an error state with a View log option for the update log. If the system cannot update automatically (for example a package conflict), it shows the steps to resolve it over SSH.

One failing module does not stop the rest ​

An upgrade applies the panel and every installed module. A module that fails to upgrade no longer aborts the chain: each remaining module is still attempted, and the update status names the modules that failed instead of only reporting that something went wrong.

The log at bolt-update.log ends with a summary line for every module, saying whether it was upgraded or failed and with which exit code. That summary is the fastest way to see what is left to fix after a partly failed upgrade.

Reading the underlying error ​

View log shows the real cause of a module failure, that is the package manager output or the response from the agent, rather than only the generic installer message. Start there before retrying the upgrade.

Scheduled checks never collide with an upgrade ​

The scheduled update check and a running upgrade are serialised, so a check that happens to fire mid-upgrade cannot interrupt it. Package metadata refreshes are also limited to the AdminBolt repository, so a routine check never triggers a full metadata download from every repository configured on the server.

Note: Before this behaviour was in place, a scheduled check running at the wrong moment could make a healthy upgrade report a failure. If you have seen intermittent "upgrade failed" messages that resolved themselves on a retry, this is the cause.