Previously, I was using my router with the IP 192.168.0.201:8443 to connect incus os installed on device via the router’s gateway, and everything was working fine.
I have now added an OPNsense firewall to my network, and the system has been assigned a new IP address: 192.168.1.186. However, I’m unable to access it using this new IP.
Additionally, when the Incus OS starts, it hangs for a few minutes displaying the message “Starting application,” and eventually fails with a “timeout exceeded” error.
I’ve attached a screenshot for reference. I have two NIC , eno1 has same issue.
The default Incus configuration on IncusOS binds :8443 so that it can handle IP address changes without any issue. Most of the Incus listeners are also non-fatal so if they can’t bind a specific IP address on startup, they just keep trying in the background.
The exception to all that is when clustering is enabled (even if single-node) as the cluster database expects stable IP addresses for all connections, starting a system with clustering enabled with a different IP address would result in what you’re showing here.
You’ll need to at least bring the system back online on a network that will give it its old IP address back. Once you’ve done that, you can add your old IP address as a static address on your network interface so it will always have that address available even when connected to your new network.
Thanks @stgraber , I actually was setting up a testing cluster so just reinstalled everything instead of brining back old network, I understand incusOS is stateless but imo It would be great if there is an option to enter for debugging purpose into shell at startup
since I am testing some scenarios, is that possible to update cluster/nodes with new IPs?
for now I am getting IPs like 192.168.x.x and want to move to 10.10.x.x which will make cluster again unreachable. any way to replace the IP’s of nodes/cluster?
Thanks
Not supported on IncusOS and a pain to do on non-IncusOS. You basically need every server fully offline (no running Incus daemon or instances), then manually edit the database headers to replace IP/DNS info and make sure the roles are correct, then both local and global DB patches to replace the IP/DNS in there too.
It tends to be easier to have both subnets work concurrently on the L2 network, then empty, remove from cluster, factory reset, rejoin with new IP, moving stuff around as you go.
