Before Xmas 2019, I was using Ubuntu 19.04. Yes, I hadn’t updated to 19.10 though every single day, the Software updater was complaining “A New version of Ubuntu is available. Would you like to upgrade?”. Using 19.04, I knew that sooner or later I would have to upgrade as by January 2020 would reach EOL, then, no updates, no security updates…. Panic!

As far as I remember, updating from some release to the next one has been always a pain in that place. I usually did that on Friday afternoon, after work, because I presumed that I would end up spending the whole weekend fixing the mess caused by the upgrade. Actually, I never knew why the upgrading process was so hard, might be because everything in this box is AMD, it’s triple booting Windows, Haiku and Linux,…I don’t know. Might be witchcraft?

Not that I really panic when I upgrade the box, because I already plan ahead to avoid as much hassle as possible, having separate partitions for whatever need, /home, /data, /projects… some on different drives, so a clean install usually means that only the system is installed, settings are kept, as well as data. No need to wipe out any disk but the system (root) partition. Minimizing the trouble, which only needs to do clean install of the OS and reinstall all the software.

1st Rebase

This story has suffered a big change this year. After doing some testing during Xmas holidays, this January 2020, I moved almost everything to Fedora Silverblue, release 31, and on April 27, Silverblue release 32 was ready to roll.

After all those “good” experiences along those years, I was ready for testing the new update, of course thinking about the weekend as the best time to do it on the Gamedev box. I also did some testing before.

Img.1 – Silverblue 32 available, Rebasing on the Terminal

I started the rebase process on the WorkAtHome disk, mostly because the Silverblue install there is quite simple not having layered anything but the Fedora Workstation repositories and Gnome-tweak-tool. Software is just office software, all flatpaked, so seemed like a good candidate to do a first Rebase test.

For this rebase I used the Terminal method, mostly because this was my first time, with Rebasing, with Silverblue, and with an OSTree based system and, to be honest, I didn’t know that rebasing was going to be available through Software Update, so what the heck, fire up a terminal, fire up Firefox with Fedora Magazine rebasing tutorial, and ready to roll.

Besides, who said fear having rollbacks available!!

Img.2 – rpm-ostree status: after Rebase

Updating to Silverblue 32 through the terminal was quite straightforward, it didn’t took so much time to update actually, even the disk is a mechanical USB 2.0 external. I did uninstall the Fedora workstation repositories as well as Gnome-tweaks to start the upgrade with a clean unlayered OS, just in case. On Img.2, there is a clean Silverblue 31 pinned, 31.20200422.0, in case of need to rollback. As of today, it’s still there. Pinned. That deployment will still be there for some time, at least until some more 32 updates come out and using 32 proves to be stable enough for not needing to keep that deployment laying around, even any Silverblue 31 deployment.

By the end of April 28th the first Rebase was a success. It didn’t took too long, around 15 minutes if I recall correctly, and everything seemed to be working properly. Therefore, ready to move on.

Rebase, reBase, rebaSe

Next in the row was the HTPC. This box also had Silverblue 31 installed, but the software installed is quite scarce, being just Kodi, Firefox, and some utilities to check just in case. Also Fedora Workstation Repos, and Gnome-tweak. Later I will need to add Google Chrome, not that I’m happy with doing so, though it seems to be a need in order to gain access to certain services.

I was ready to use the Terminal here too, though thinking about using the tiny keyboard (Img.3) to type everything would have make it a bit slower.

Img.3 – Tiny Keyboard for HTPC

Nonetheless, it wasn’t needed in the end (Img.4), as Software Updater notified that a new version of Silverblue was available to download. This time, and after some other users pointing out that they didn’t need to unlayer certain packages, I did let the update do its thing without prior preparation.

Img.4 – “Rebasing” with Software Updater

No need to say that the HTPC also updated in a short period of time, also without issues, and upon reboot, Silverblue 32 was ready to roll with Kodi there, working.

I did update these two boxes prior to updating the Gamedev box to gain some experience on the process, and because the software installed on both does not need any strange layering, as requirements are lower than those of the GDB.

The big R-E-B-A-S-E

With May the 1st around the corner, a 3 day weekend was on the horizon, ready to do the BIG rebase of the GDB. While both prior rebases proceeded smoothly, without any issues, I didn’t expect this one to be as straightforward. Nonetheless, I did want to test how the process would be.

Img.5 – rpm-ostree status, as of April 6th.

In order to work properly with Audio and Video, there is a need to install some Codecs on Silverblue (seems also on Workstation), that are available through rpmfusion. The process of adding those codecs is explained in Fedora Silverblue: installer les codecs multim├ędia. After following the steps pointed out on that tutorial, we end up with some packages layered, some plain layered, and some layered as local packages. I presumed that Silverblue update would not allow to complete the upgrading process with all these packages there, though I checked the possibility nonetheless.

Img.6 – Upgrade fails

Upgrade failed, as expected. I did use Software Updater instead of the Terminal to do the rebase, just because the update appeared available when I opened Software to search for some tool, and because I wanted to check if Software would be available to fulfill the upgrade, as would be expected by a regular user. Also, by doing this, I checked that Software Updater didn’t allow the upgrade to take place as not all requirements were met, though the message was not so clarifying. On this case, I know what the 2 problems were, but on a different situation I, or some others might not. A message telling the user that some layered packages are blocking the upgrade process would be much better in order for the user to address the issue.

No need to say that once all those layered packages were removed, local and plain layered (leaving fedora-workstation-repos, gnome-tweak-tool and variety untouched), the upgrade process did complete without any issue, and in less than 15 minutes, the new Silverblue 32 was up and running inside the GDB.

Img.7 – rpm-ostree status: already on Silverblue 32

After the upgrade, some pinning was done (Img.7, pinned 32.20200502) on the first clean updated deployment, prior to layering again all the codecs from rpmfusion.

The upgrade, if we don’t take into account the issue with the layered codecs, was a very safe process, and I didn’t need to do a clean install, nor I had to reset any configuration anywhere. So yes, this was the first time in years that I upgrade Linux computers almost flawlessly. And I say almost, because not everything is perfect yet.

THE FLAWS

Img. 8 – OBS Studio is not responding

After the upgrade, it was time to get back to doing some work again, and show it off. Surprise, surprise, OBS Studio crashes on start thus no way to record a screen cast, be it window, desktop or whatever; and Peek locks everything until it crashes or stops, not being able to do anything outside the Peek headerbar. Other than these two issues, I haven’t found any major flaw after the upgrade process, though I must say that I haven’t got into deep yet. In the next days I will be able to verify that every other piece of software is working properly, or at least, with some minimum reliability requirements.

Img. 9 – Grub Menu: still duplicated entries

A known issue with Silverblue 31 was the duplication of GRUB entries at boot. Well, they are still there, though some have reported that this duplication has disappeared after rebasing to 32, I can’t say the same for now, though they might magically disappear in the near future (witchcraft again?).

I did remove some Gnome software though, Gnome Maps wasn’t working at all, only loaded the map inside the window, then nothing more could be done there but staring at the static image. Removed. I did also remove Gnome Weather, Clocks, Calendar… But this is another issue not related to Rebasing that deserves a different article.

In case of remarkable news that alter what has been said here, I will update the info properly, though I wouldn’t expect that. Silverblue has proven quite stable in version 31, and for now, it looks fine.

Toolboxes

Regarding toolbox, though I haven’t used these so much in the past months, I have them there waiting for time to work on some projects.

Img. 10 – toolbox list: toolboxes created on 31, available on 32

And yes, the toolboxes are there, and they are working, though the base is Fedora Workstation 31, which is the base with which they were created. I wouldn’t expect anything different from this. Maybe when I really get to them, I would update them to an image with base on Workstation 32, maybe 33, who knows.

Conclusions

The updating process provided by Silverblue has proven quite smooth. To anyone without specific requirements, and without special layered packages, in my humble opinion, it’s the way to go. Any regular user or any user coming from MS Windows or OSX would appreciate (I presume) this process, because:

  • the process is quite straightforward if started from Software, thus no need to use the Terminal to Rebase, avoiding the FGS (frightened geek syndrome)
  • the upgrade process is quite fast, being downloading the update the process that takes up most of the time. On reboot the new system is ready to go, no waiting for “updating system” nor on shutdown, nor on startup
  • does not, mostly (at least in my case some issues have risen after upgrading, affecting 2 programms), affect installed software as only System is updated, software, as long as flatpacked, has a different upgrade channel
  • rollback is there in case something goes wrong, so user can go back to a stable system and still be productive while the upgrade process improves, and fixes the issues

In the end, some issues still need to be ironed to render the Rebase process perfect, though anyone who knows anything about quality, knows that 100% perfection is impossible, reaching 90% is doable, and increasing each 1% from there becomes more and more expensive (exponentially), in time cost, and coin cost. So lets accept perfect as being relatively perfect and call it a day, with the advantage that each user would accept different degrees of relativity, I presume.

The issues shown by OBS and Peek got me a bit puzzled, as I expected, being them flatpak software, nothing would go wrong with their behavior after the update. Really I have no clue on what happened here, though I presume that it might have something to do with the provided SDK; though being the software sandboxed, and presumed distributed with the right SDK, it does not make much sense that these software crashed. Or maybe something happened with the video driver after the upgrade. I don’t know. As pointed out by @FastOSlinux via Twitter, this issue is documented, at least the one related to OBS, in Github.

Even with these flaws, I personally think that the upgrade process provided by Silverblue is the best available in the Linux distro world. And by that I mean that immutable OS distros with atomic updates is the way to go. Having rollback available is a life saver in the case of an upgrade breaking the system, and while I can remember to pin a deployment before upgrading, it would be nice that when triggering an upgrade, the system automatically pins the last active deployment “just in case“, as I presume not all users will remember that.

Pros

  • Fast process
  • Options to use Terminal (geek) or Software Updater (regular)
  • OSTree rollback guarantees a stable system to go back to in case of trouble
  • smooth for non layered systems

Cons

  • Not friendly with certain layered packages
  • Strange crashes of certain flatpaked software after update
  • Would be nice to have more info on why the upgrade fails

With the goods and the bads, Silverblue is on the right track to manage upgrades, and will just get better.