Unattended upgrades on Proxmox and Debian: the package list that has to stay manual

unattended-upgrades aborts any change that would remove a package. Its sanity check discards the transaction the moment one package is marked for deletion, and the package that needed the removal is quietly kept back. That is exactly what apt upgrade does — and the Proxmox administration guide is blunt about that mode: “performing an apt upgrade may result in a partially upgraded or broken package state”. An unattended run cannot switch to full-upgrade; the refusal sits in the code, not in the config file.

So the question is not whether you may automate Proxmox updates, but which part you hand to a tool that will never remove a package. Kept-back packages do not announce themselves — they end up as a line in /var/log/unattended-upgrades/unattended-upgrades.log.

Two origins, two decisions

The repositories on a PVE host identify themselves differently. Debian security publishes as Origin: Debian, Label: Debian-Security; the Proxmox repository as Origin: Proxmox, Label: Proxmox Debian Repository; and Ceph carries a label of its own, currently Proxmox Ceph 19 Squid Debian Repository. A pattern aimed at the Proxmox label therefore misses Ceph, and the other way round. Security only, nothing else, is this:

Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

The template shipped with the package has a third active line that is easy to miss, ending in label=Debian rather than label=Debian-Security. That is the ordinary stable archive, not the security one: leave it in and every Debian point release lands on your hypervisor overnight, in one batch. That single line is the difference between security-only and everything.

The blocklist — and why the obvious one is wrong

The obvious first guess is proxmox-ve, pve-kernel, pve-manager, qemu-server, pve-qemu-kvm, pve-container. It has two faults. First, pve-kernel no longer exists on Proxmox VE 9 — that branch ships proxmox-kernel-6.14, the signed per-version packages and the meta package proxmox-default-kernel. Second, if your pattern allows Debian security alone, none of them could be touched anyway: they all come from the Proxmox origin, as do zfsutils-linux, corosync, ifupdown2 and ceph-common. On a PVE host those are Proxmox packages, not Debian ones. A blocklist earns its place only once you deliberately allow origin=Proxmox — and then every entry needs a reason:

Entries are regular expressions anchored at the start of the name only, so libc6 also catches libc6-dev unless you write libc6$. For anything that must never move, apt-mark hold is sturdier — it also stops the full-upgrade you type yourself at two in the morning.

The mistake before the first nightly reboot

Automatic-Reboot defaults to false, and if you switch it on, Automatic-Reboot-WithUsers defaults to true — your own open session will not hold it back. The trigger is the file /var/run/reboot-required, written on Debian by a kernel hook that the unattended-upgrades package installs itself, so before the install it never existed and its absence proves nothing.

Then the part that really hurts. The onboot option defaults to 0 in both qm.conf and pct.conf — a guest starts at boot only if you said so. A host that reboots at 02:00 comes back with every VM and container someone started by hand still switched off. Check before, not after: grep -L '^onboot: 1' /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.conf lists exactly the guests that will not return.

The clock misleads too. The run is triggered by apt-daily-upgrade.timer at 06:00 with a randomised delay of up to 60 minutes, and unattended-upgrades then calls shutdown with your Automatic-Reboot-Time. Put 02:00 there and you schedule the next 02:00 — nineteen to twenty hours with the new kernel installed and the old one running.

needrestart runs along and does nothing

Services do not restart when only one of their dependencies was upgraded; that is what needrestart is for. Its shipped configuration states the problem itself: “If needrestart is configured to run in interactive mode but is run non-interactive (i.e. unattended-upgrades) it will fallback to list only mode.” The default is interactive, so on an untouched install the automated run lists the services still sitting on old libraries and restarts none. $nrconf{restart} = 'a'; makes it act — a deliberate decision on a hypervisor, where restarting a storage or cluster daemon unannounced is not the same as restarting a web server.

Without apt: dnf-automatic

On RHEL, Rocky and Alma the counterpart is dnf-automatic, configured in /etc/dnf/automatic.conf and enabled through dnf-automatic.timer (on dnf5 systems dnf5-automatic.timer). Three switches decide everything: upgrade_type with default or security, apply_updates, and reboot with never, when-changed or when-needed. There is no direct equivalent of the package blocklist — excludepkgs is a per-repository option in dnf, not something you set in automatic.conf. Cleaner design, blunter instrument.

What is left for a human

Set up this way, the host keeps its Debian half current and does not touch the Proxmox half. That split is correct — and it means the Proxmox half now depends on somebody noticing that a release happened. Proxmox does not run an announcement mailing list for it. Tick Proxmox VE and Debian in the catalogue and you get an email when a new version ships — free, no account, one-click unsubscribe. As of 19/08/2026 the newest recorded versions are Proxmox VE 9.2 (vendor date 21/05/2026) and Debian 13.6 (11/07/2026); the same dataset lists 31/08/2026 as the end of support for Proxmox VE 8, and what else runs out is on the end-of-life page. The catalogue also covers the class with no apt at all — appliances and firmware, where there is nothing to configure in the first place.

The honest limitation

All of this assumes the security archive still delivers for your release. For Debian 12 — the base of Proxmox VE 8 — regular security support has run out and LTS carries it from 2026-06-11 until 2028-06-30, with the caveat the LTS team states itself: how many packages are properly maintained depends on how much support the team receives. Your origins pattern does not change; what arrives through it does. And automation without looking is a habit, not a safeguard — run unattended-upgrade --dry-run --debug once before the first live night, then read the log or set Unattended-Upgrade::Mail.

Option names, defaults and the sanity check from unattended-upgrades 2.12 as shipped in Debian 13; needrestart 3.11-1; timer values from apt 3.0.3. Origin and label read from the Release files of security.debian.org and download.proxmox.com on 19/08/2026, Proxmox package names from the trixie branch of pve-no-subscription the same day. onboot defaults from the Proxmox VE manual pages for qm.conf and pct.conf. patchletter figures from our own dataset as of 19/08/2026.