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 normally run on their own

The server updates the panel + agent 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 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.