Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.
My trip is getting really close, so I decided to upgrade my system to rawhide. Wait, what ? That is usually what everybody would tell you not to do. Rawhide has this reputation for frequent breakage, and who knows if my apps will work any given day. Not something you want to deal with while traveling.
With rpm-ostree, installing a newer OS is very similar to updating your current OS: a new image is downloaded in the background, and when the download is complete, you boot into the new image. The previous image is still available to boot back into, as a safety net. That is the reason that I felt confident enough to try this a day before a major trip:
rpm-ostree rebase \ fedora-ws-rawhide:fedora/rawhide/x86_64/workstation systemctl reboot
I would love to say that things went perfectly and I was back to a working system in 10 minutes. But it was not quite as easy, and i did encounter a few (solvable) problems. It is worth pointing out that while I was solving these problems, rpm-ostree had already downloaded all of the rawhide image, but I was still safely running my F27 OS. At no point was there a mess of a half-upgraded system with a mix of old and new rpms. I was running my old system until I had solved all the problems and had a OS image that was ready, and then I booted into it. A safe, atomic switch.
Problem 1: The rpmfusion repo is not available for f28 yet. It is a common occurrence that 3rd party repositories lag behind the Fedora releases a bit, so this is not surprising. It is a bit unfortunate that i had to remove my layered rpms from the repository to work around this.
Problem 2: buildah now in the base image. This is a good thing, of course, but it caused rpm-ostree to complain about the conflict between the OS image and the layered package. In this case, I removed the layered rpm without any qualms.
Problem 3: Rawhide repositories had a bad day. For some reason, they were missing the repomd.xml file today.
This is a good reminder that as long as you are using package layering, you haven’t really left the world of yum repositories and out-of-sync mirrors behind. rpm-ostree has to check the yum repositories for updates to the layered packages, which means that it can be hit by the same issues as dnf on a traditional Fedora workstation.
For my rebase to proceed, I had to remove everything that was layered on top of the OS image. After I did that, rpm-ostree no longer needed to look at yum repositories, and switched my system to the already-downloaded rawhide image.
After the reboot, I’m now running rawhide… and all my applications are just the same as they were before. A nice aspect of the Atomic Workstation approach is that (flatpak) applications are decoupled from the OS. I can update the one without the other. We are not entirely there yet: as you can see in the screenshot below, a number of applications are still installed as part of the OS image.
More importantly, the screenshot shows that GNOME software will support updating the OS on the Atomic Workstation in Fedora 28. It does so by talking to the rpm-ostree daemon.
Switching from one Fedora release to the next ls already working pretty well in the last few releases. With the Atomic Workstation, it can become as undramatic as installing the latest updates.
3 thoughts on “Fedora Atomic Workstation: Works on the beach”
Great blog posts, Thanks a lot!
I happen to be in a similar situation today with applications updates.
Here is a screenshot of gnome software without inverted colors if you want to use that instead.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
Great post, thanks. Atomic really feels like the way we need to go. 🙂
As for apps, I’ve been running eog and Clocks from Flathub for a while now, without any issue. So that’s two you can remove from that screenshot above. 🙂
RPM Fusion is working as appropriate from the beginning for f28. But because we do not branch at the same time as fedora for obvious reasons. (Let fedora branching to stabilize among others).
(when you will see a rpm with version 29, we will start to support 29, so it’s not an issue for f28)
Comments are closed.