"Wait for other cluster nodes to upgrade their versions"

Incus
1

Hi all,

I ran cluster evacuate followed by apt-get upgrade and a reboot on a member of an Incus cluster, and that node is now waiting for the rest of the cluster to update:

“Wait for other cluster nodes to upgrade their versions, cluster not started yet”

What was a bit concerning to me though was the errors printed when running the upgrade:

Setting up incus-base (1:6.12-debian12-202505151618) ...

Job for incus.service failed because a timeout was exceeded.
See "systemctl status incus.service" and "journalctl -xeu incus.service" for details.
dpkg: error processing package incus-base (--configure):
 installed incus-base package post-installation script subprocess returned error exit status 1
Setting up perl (5.36.0-7+deb12u2) ...
Setting up libgcc-12-dev:amd64 (12.2.0-14+deb12u1) ...
Setting up libgssapi-krb5-2:amd64 (1.20.1-2+deb12u3) ...
dpkg: dependency problems prevent configuration of incus:
 incus depends on incus-base (= 1:6.12-debian12-202505151618); however:
  Package incus-base is not configured yet.

dpkg: error processing package incus (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of incus-ui-canonical:
 incus-ui-canonical depends on incus; however:
  Package incus is not configured yet.

dpkg: error processing package incus-ui-canonical (--configure):
 dependency problems - leaving unconfigured

After the reboot, I tried running an upgrade again because for some reason linux-headers and linux-image hadn’t been upgraded – despite not being in the list shown by apt-get though, it’s now “Setting up” incus-base again and hanging, just like before the reboot:

Setting up incus-base (1:6.12-debian12-202505151618) ...

So I guess my main questions are:

  1. What is going on with these incus packages?
  2. With my first node in state EVACUATED and the other two BLOCKED, what is the best way to proceed with minimal downtime? Just upgrade the two BLOCKED nodes, reboot and hope for the best?
  3. To avoid this in future cluster setups, I guess I should be using the LTS repo and not stable? Or is this something that happens frequently between LTS updates as well?

Thanks in advance

2

When updating to an Incus version which comes with a database change, ALL servers must be updated concurrently. The update will remain stuck until all servers have reached the same stage.

3

So does this mean that the reason for the:

Job for incus.service failed because a timeout was exceeded

Is because it’s waiting for the other nodes in the cluster to upgrade during the apt upgrade?

Also, even if it might be obvious, I’d appreciate some clarification on the difference between stable and LTS here – are database changes something that can be expected in LTS as well, or is this a moot point because clusters should always be concurrently updated regardless?