#1

Hello Silverblue specialists :slight_smile:!

I have a general (and probably simple) question:
How is (rpm-)ostree itself updated?

Is it just part of a normal ostree update (I can’t think of something else)?

Scott Trakker

Message from The Netherlands :netherlands:

#2

https://docs.fedoraproject.org/en-US/fedora-silverblue/updates-upgrades-rollbacks/

#3

No, I mean to software ostree itself!

#4

From what I understand so far of the Silverblue setup, ostree is part of the base image. So, it’s updated too (via rpm-ostree itself), as tungdil hinted. :grinning:

1 Like
#5

Hello @scotttrakker,
I am by no means an expert of Silverblue, but I will try to answer your question as best I can. Silverblue, and Coreos are both immutable operating systems based on ostree. They use rpm-ostree as a way to have the “best of both worlds” of an immutable OS and a more traditional Workstation type OS that is entirely mutable. Rpm-ostree is derived from ostree, so as ostree receives updates, rpm-ostree would follow suit under the normal CD/CI cycle in cadence with Fedora’s release cycle. Thus we get, as users, a tested core OS that is provided as an immutable whole at update time. Plus, we also get the ability to add to, override parts of, and generally messup our immutable OS with the addition of the DNF libraries which (simplistically speaking) give us the RPM in rpm-ostree. Also, if our tweaking results in a non bootable OS, we simply boot the previous working state and we are back running. There is a whole lot more info Here that is some good reading on the subject.

#6

That is right! rpm-ostree and ostree are just rpms that are part of the base OSTree that’s delivered.

1 Like
#7

Hi Jakforst,

Thank your very much of your elaborate answer but I know what (rpm-)ostree is and how it works. The only thing that I didn’t understand was how (rpm-)ostree itself is updated. I mean the software (rpm-)ostree itself. The answer that @madalinc gave, was the anser that I was looking for.

Nonetheless, thank you very much for the answer!

1 Like
#8

Thank you very much! This was the answer I was looking for!
Is it not error prone that (rpm-)ostree updates itself? Is it not now the ‘Achilles’ heel’ of the whole system?

I mean if there was a bug in (rpm-)ostree and that bug was propagated to every system, wouldn’t you have the danger that all those system might not even update anymore (worst case scenario)!?

Having said that, this problem would also occur if (rpm-)ostree was separated from the rest of the system. An update to a vital part of a system is always dangerous.

1 Like
#9

Thanks you very much for the confirmation.

1 Like
#10

You’re right on the dangers of an error in the updater script being a single point of failure and it could propagate to all users. As a side note, the code is on GitHub, so updates could be rolled back in case of some (unlikely) critical error in the ostree script itself.

That being said, one could argue that the whole system (base image) has the same Achilles’ heel. All the system images are the same, so a bad image is going to be bad news for the whole community. :sweat_smile:

Given how easy it is to revert changes/updates, I would be pretty relaxed about this possibility. Plus, the devs are awesome at what they’re doing with Fedora in general, so there’s this, too. :vulcan_salute:

1 Like
#11

If the worst happens and a bad image breaks the updaters, a workaround would be to unlock the base image and install fixed RPMs.

The default bahaviour though is to keep the previous deployment, but the tooling on rolling back should probably be more exposed in the UI.

1 Like