I normally have Zincati disabled, as I want complete control of when my PC updates and reboots. I am now trying to update my PC manually by starting the Zincati service, but am getting this error in the journal:
systemd[1]: Started zincati.service - Zincati Update Agent.
zincati[52316]: [INFO zincati::cincinnati] current release detected as not a dead-end
zincati[52316]: [INFO zincati::update_agent::actor] target release '39.20240104.3.0' selected, proceeding to stage it
zincati[52316]: [ERROR zincati::update_agent::actor] failed to stage deployment: rpm-ostree deploy failed:
zincati[52316]: error: Cannot look up version while pinned to commit
Is this because I have a deployment pinned? Is this intended behavior? If so, is there another way for me to update the image and packages, but also have the option of reverting the PC back to its original state or one of several prior states if I need to?
Yes this is the method I have used to disable Zincati, sorry for the poor wording in my initial post. In my attempts to update the system, I would change it to enabled = true and restart the service.
The manual upgrade through rpm-ostree does not seem to upgrade the image, but only the layered packages. Am I perhaps using it wrong? Is there a way to get it to update the image also?
pinning a deployment here isn’t going to work out well because we have really limited space in the /boot filesystem and you’ll end up hitting other problems that will prevent upgrade if you try to keep 3 copies of the kernel and initramfs around. You need to unpin the deployment and let zincati work.
On any upgrade the currently running depoyment (the one being upgraded from) will never be deleted so you’ll always be able to roll back unless zincati does multiple updates in a row (which can happen if your system is out of date) . My suggestion here is for you to disable the zincati service by default so it won’t run on boot, then only start it when you want to update. Don’t pin deployments.
So the pinned deployment is what is ultimately causing the error and preventing me from updating the system? This is intended behavior?
That is really unfortunate, I had hoped that CoreOS would allow me to keep a “known good” state around until I can absolutely verify the update is working exactly as expected (which could take days or weeks). As you say, if multiple updates occur then that known good state is no longer available and I could end up with a broken system with no convenient methods to restore it.
but I told you exactly how to do that above. Just systemctl disable zincati.service so it won’t start by default on boot and then only systemctl start zincati.service when you want to do an upgrade.
The number of upgrades you ever have will correlate directly with the number of times you type systemctl start zincati.service.
I think I understand, except for how this would work with multiple updates in a row.
Let’s say my PC is currently on deployment A, and I want to update to the most recent image, deployment C. There is also a deployment B, a less recent image that is a week older than deployment C.
I unpin A, allowing Zincati to update to deployment B, then C. Both deployments B and C have bugs for the software I’m running. Since I had to unpin A to perform the update and only 1 previous deployment is kept around (B), I am left with a broken system.
What could I do in this situation? I suppose I’m trying to determine whether pinning deployments is an unsupported use case in CoreOS, as it seems to prevent system updates from occurring?
What if my apps are definitely broken on B, but could potentially be fixed on C? Is there no supported method of reverting back to A if I update and find that C is still broken?
For some context, my PC is currently running an old image because when I updated to a newer image it was affected by a GPU driver bug. That bug might be fixed now, but I cannot update to the latest deployment without potentially losing the one that currently works.
Really though, it would be better if you had a second system (or a VM or something) where you can test things before deploying them. So you’ll know if C works before you even start to update that system that you really care about.
!