Silverblue 32 - S01E02: The first update!

So you installed Silverblue 32, and the first thing you wanna do is to update. Like you do in every other Linux! But unlike any other Linux, everything is quite different here. I’m going to start the update with something that will seem very weird, and that is opening GNOME Software. It may be awful everywhere else, but theoretically it should work flawless in an OStree System. So I’m going on Updates page, and what we are interested here is the OS updates.

00:52 - On top we have the additions that are new packages to be installed. Then we have some removals. We have the actual updates, and if we scroll to the very bottom, we will see some downgrades too. One thing to notice here is that all transactions are atomic and safe, which means either everything is completed, or nothing is done. But everything extends beyond that. Even in an upgrade, for example from Silverblue 32 to 33, it is virtually impossible for a transaction to fail, or at least it will never leave you with an unbootable system. But lets close all those and open a terminal.

01:28 - We don’t really need it for an update, I just want to show you a few things! Typically, we start with rpm-ostree status, to get the basic information about our system. First we have the state which is idle, meaning there are not running transactions. Then is the Automatic Updates field that is disabled. But let me quickly show you how we can edit policies. We want to open the rpm-ostree configuration daemon, that is under “etc” directory. Now we see that Automatic Updates are set to none, so we can uncomment this and for example set them to check. Which means it can just check for new updates. Then we need to reload the rpm-ostree deamon and run status again. And now we see that automatic updates are on check mode, but we also had to enable the timer, which I didn’t. Basically I’m not going to bother with all those right now, so I will revert everything back.

02:32 - I just wanted to quickly show you how about it works. On a next episode I will show you how we can even enable automatic updates staging on background. Reload the service again clear everything, and back to status. The second we are interested at, is the actual deployment. This bullet tell us that is the active deployment, but since we come from a new installation, we only have a single image anyway! And the third is the commit we are currently at.

03:06 - Basically OSTree is a Git-like filesystem, so if you’re looking for a true rolling release Linux, it is not Arch Linux. Silverblue is the pure thing, and I will expand on another episode! Okay, to finally make an update, we say, rpm-ostree update, and notice that staging the updates doesn’t need root privileges. Also, the correct command is rpm-ostree upgrade. Update is an alias! My bad, sorry! Another thing is that the packages were downloaded already. That was a behind the scenes job of GNOME Software.

03:41 - I think! Anyway, update is done, so lets clear, and run status again! And now we have two deployments. On bottom is our current and on top is called the pending deployment, and we can use it after we reboot. It also says the difference from the current, with 212 upgraded packages, 24 downgraded, 2 removed, and 15 added. Okay, lets get crazy! When you boot on your normal Linux, you get a menu to pick the kernel. When we boot in Silverblue, we get a menu to pick the deployment! Since we have two deployments, we can either boot on the image with the updates, or we can boot on our current image without any updates.

04:26 - I’ll open a filemanager to quickly show you how that works. And I know I’m now jumping from one topic to another without explaining anything in depth, but these are just intro videos, and I will go in detail in dedicated episodes! So, on /OSTree, we have the boot directory that has the boot configurations, and basically the boot links to deploy folder, that is the directory that Silverblue deployments are physically stored. So we see our 2 deployments. Anyhow, I’m going to close this and finally reboot! By the way, there is a way to mount a pending deployment without rebooting. But at the moment is highly unstable, and it is the only way to destroy a Silverblue really!! Okay, so we now are on grub menu, and we basically have two entries. The first entry is our top of the list deploy with the updates, and it is indexed as 0.

05:20 - The second entry is the original deploy before the updates, and it is index as 1. We have two more entries that are identically labeled, that are useful when we are doing layering, but in this case is just a bug. But that’s the entry we want to boot, and if we press “e” to go on edit mode, we’ll see that it boots the deployment from the OSTree directory I showed you before. Anyway. Escape and go! Very well! Now we see our two deployments again. This is called the active and is index as 0, and that’s the rollback and is index as 1.

06:13 - As I told you before, OSTree is a Git-Like filesystem which means it works like a COW which means that deploy 0 only keeps the changes from deploy 1, to save some space. If we want to see what are those changes, we can do, rpm-ostree database difference, and we want to compare this commit, with this commit. And we’ll see what has been added, what has been removed, what has been updated etc. OSTree alone isn’t really a package manager, but a tool to manage versioned filesystem trees. In Silverblue they have added to it RPM capabilities, that’s why it can do stuff like those. Okay, now.

06:56 - By default Silverblue will keep the last two deployments which is enough for the most of the cases. That means if we do a new commit, the deployment 1 will be removed. But let’s suppose we want to keep it. What we can do is to pin it. So, sudo ostree admin, and pin 1. So now it will tell us that the deployment 1 is pinned, and if we go on status, we will see this message again! Obviously, pinning a deployment is meant to use for short term, and we really don’t won’t to end up with 100 pinned images, and 200TB disk space! But we can do if we want! Now, if we want to restore deployment 1, we can do rpm-ostree and rollback. That will remove deployment 0, and deployment 1 will become the active. And the only one really. If we want to remove this to free some space, we can do rpm-ostree cleanup, and -r, which means rollback.

08:01 - But I imagine it won’t work because it is pinned. So deployments unchanged, as I told you so! But if we unpin it, sudo ostree admin pin and unpin 1 and try again to cleanup the rollback this time will remove it and it will save us 1GB of space. One last rpm-ostree status, and now we will have a single deployment! Exactly as we started but fully updated! So, I’m closing this, and I’ll see you on the next episode! .