Looking in /var/log/apt/term.log, I can see Removing incus (6.0.3-2~bpo12+1) Removing incus dnsmasq configuration
which I can’t understand for the life of me.
Why would apt upgrade the client to 6.0.4 and drop the server 6.0.3!?!
(because the client might be managing a server elsewhere?)
I have not rebooted and my containers are still running currently.
What is the easiest way to resolve this?
Can you try apt install incus incus-client incus-agent to force APT to resolve all three together? It should at least tell you what’s going on at that point.
The organization of Debian’s Incus packages was tweaked in version 6.0.3-3. There’s a NEWS entry if you’re interested in the details. Because you’re using the backported version of the package, apt won’t automatically pull in new dependencies, such as an updated QEMU, without some extra hand-holding.
If you only are interested in running containers, apt install incus-base -t bookworm-backports should get you fully caught up. If you’re also needing to run VMs, run apt install incus -t bookworm-backports.
PS – apt won’t magically remove a package; either it provided an upgrade solution that included the removal of incus, or you ran something like apt dist-upgrade -y which is dangerous.
sudo apt install incus-base -t bookworm-backports has restored operation.
I also sudo apt install incus -t bookworm-backports and just got a warning about virtiofs for Qemu.
Not sure where to be looking fo the news article you mentioned. I searched on the https://linuxcontainers.org/incus/news/ page, but didn’t see anything about 6.0.3-3.
I’m still confused, why would apt mark 6.0.3 for removal when 6.0.4 LTS exists? It did after all install client 6.0.4.
I’m running backports, as that’s the recommended way if playing by the book isn’t it? The raison d’être is reliability.
Ironically, the upgrade notes for Trixie (when it becomes stable) is to perform apt full-upgrade first, which is what I was doing in preparation.
I believed by following this strategy I had a reasonable expectation of reliability.
I’m sure apt warned me that incus would be removed and I foolishly didn’t read this warning. I have noticed when doing apt upgrade in the past, that later versions are being held back, because they’re due for release in Trixie.
Am I going about things in the wrong way? Isn’t backports the ‘safe’ way?
The NEWS entry is part of the Debian packaging. Tools like apt-listchanges will display relevant NEWS entries when updating a package.
Bookports is the best way to run newer versions of packages on a stable Debian system, since those package(s) will be part of the next stable release ensuring a clean upgrade path. Due to apt repo priorities, packages from backports will never be selected, unless explicitly listed during an install/upgrade command, or a version from backports is already installed. Usually this works just fine, but when a binary package reorganization occurs (like with incus 6.0.3-3), or a new dependency is added that’s only available from backports (like a newer version of QEMU required by Incus), apt can’t automatically resolve the situation. It will do the best it can, such as upgrading incus-client but not incus.
The dangerous bit of apt dist-upgrade I listed above is the -y option; that causes apt to automatically apply its “best” solution, which can involve automated removal of packages.
I routinely use backported packages on my various Debian systems, but remember the disclaimer on the front page: “Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!”
