Problems & Fixes¶

This page collects the most common operational problems and how to fix them yourself. Each entry follows the pattern Symptom → Cause → Fix. Run the fix steps over SSH as root (or with sudo) directly on the affected server.

Updates only run on their own in \"Automatic\" mode

The update mode defaults to Manual: the panel + agent are only installed when you trigger it. In Automatic mode the server updates them by itself from its release channel (unattended-upgrades, usually overnight). You only need the fixes here if an update is stuck or you want to force it right now.

Panel update stays on the old version¶

Symptom: Under System → Update an update is started, but after reloading the old version is still shown. The "Update" button appears to do nothing, and no error is displayed.

Cause: A third-party repository (typically the MariaDB package mirror) is causing trouble — in one of two ways, both with the same symptom:

Variant A — changed metadata: the repo changed its Origin or Label value:

E: Repository '.../mariadb/... trixie InRelease' changed its 'Origin' value from 'MariaDB' to 'debian trixie'

Variant B — repo fully unreachable: the mirror returns a genuine 404 for its own Release file (e.g. during a MariaDB infrastructure outage):
```
E: The repository 'https://deb.mariadb.org/11.8/debian trixie Release' no longer has a Release file.
```

(both messages may appear localised in the server's language). In older panel versions (< v2.8.53), the panel update script runs under set -e and exits on any kind of repo failure before the actual install — even though our own repo (git.netcell-it.de) is perfectly reachable. Nothing gets installed and the panel stays on the old version.

Auto-healed as of v2.8.53

As of panel version v2.8.53, no single third-party repo can block the whole update anymore — neither variant A nor B. Current panel versions also create an apt configuration at startup (/etc/apt/apt.conf.d/54enconf-releaseinfo) that generally tolerates variant A (package signatures are still verified). You only need the manual fix below once, if the server is still stuck on a build older than v2.8.53 — after that it's permanently immune (including against future repo outages like variant B).

Special case: MariaDB vendor repo fully down (variant B)

If deb.mariadb.org specifically goes fully down (variant B), that doesn't just affect panel updates — it also affects installing mariadb-server itself. That package is apt-pinned (Pin-Priority: 1001) to prefer the vendor, but not exclusively locked to it. As long as the vendor mirror serves no package data at all, Debian's own mariadb-server from the main repo kicks in automatically as a fallback (currently e.g. 11.8.6 instead of the vendor's 11.8.9 — functionally equivalent, just a few patch releases older). No manual action needed; once the vendor mirror is reachable again, the next update automatically pulls the newer vendor version back in.

Fix (SSH as root on the server):

Confirm which variant applies:

apt-get update
# Variant A: E: Repository '...' changed its 'Origin' value from '...' to '...'
# Variant B: E: The repository '...' no longer has a Release file.

Refresh the package index — --allow-releaseinfo-change helps for variant A; for variant B (repo is dead) it does nothing but is harmless. Either way, it's enough to ignore the error and move on:
```
apt-get update --allow-releaseinfo-change || true
```
Update the panel + agent — existing configurations are preserved. This works even if step 2 reported an error: apt uses the last successfully-fetched package index for our own repo.
```
apt-get install -y --only-upgrade \
  -o Dpkg::Options::=--force-confold \
  enconf-agent enconf-webpanel
```

Check the version:

dpkg-query -W -f='${Package} ${Version}\n' enconf-agent enconf-webpanel

Doing nothing is also an option — with a caveat

As of v2.8.53, the automatic nightly updates (update mode "Automatic") are no longer affected by either repo-failure variant: one repository's error does not block the others. But as long as your server is still stuck on an older version, unattended-upgrades can also fail on variant B (a fully dead repo) — in that case only the one-time manual fix above will get the server onto v2.8.53+ in the first place.

"apt" is in a broken state¶

Symptom: Updates fail with messages about half-configured packages or unmet dependencies, or the panel update loops ("verification keeps repeating").

Cause: An interrupted or partial apt run (e.g. an aborted unattended-upgrade) left packages on mixed versions. The enconf package install can then not complete.

Fix (SSH as root):

dpkg --configure -a
apt-get install -f -y
apt-get update --allow-releaseinfo-change
apt-get install -y --only-upgrade \
  -o Dpkg::Options::=--force-confold \
  enconf-agent enconf-webpanel

Getting further: logs & support¶

If a fix does not have the expected effect, these logs hold the decisive clues:

# Panel and agent service
journalctl -u enconf-api  -n 100 --no-pager
journalctl -u enconf-agent -n 100 --no-pager

# Last automatic/manual update run
journalctl -u enconf-upgrade.service -n 60 --no-pager
tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

If you are still stuck, send the output of the commands above to support@netcell-it.de — that usually pins down the cause unambiguously.