Understanding Differences Between rpm-ostree and openSUSE's transactional-update

Hello Fedora Community,

I’m currently delving deeper into Fedora Silverblue and Fedora CoreOS, both of which utilize rpm-ostree for atomic updates. As part of my learning journey, I’ve come across openSUSE’s transactional-update tool, which appears to serve a similar purpose, but for their MicroOS and Kubic distributions.

I understand that both rpm-ostree and transactional-update aim to provide atomic, reliable updates and utilize an approach where a new system snapshot/version is created for each update. However, I’m interested in understanding more about the specific differences between these two technologies from a Fedora perspective.

  1. How does the implementation of atomic updates differ between the two?
  2. Are there specific features or benefits of rpm-ostree that make it uniquely suited to Fedora’s approach, particularly in the context of Silverblue and CoreOS?
  3. Are there lessons or inspirations that rpm-ostree could take from the approach used in transactional-update or vice versa?

I’d greatly appreciate any insights or resources that can help shed light on these questions. My aim is not to compare which one is better but to gain a deeper understanding of the unique design philosophies and implementation choices behind these technologies.

Thank you in advance for your time and knowledge!


1 Like

rpm-ostree pulls down a pre-built ostree image and then optionally applies some changes to it locally:

From coreos.github.io/rpm-ostree:

It combines libostree as a base image format, and accepts RPM on both the client and server side

openSUSE transactional updates do not use pre-built images but operate with btrfs snapshots.

From kubic.opensuse.org/documentation/transactional-update-guide:

Conceptually transactional-update creates a new snapshot with btrfs before performing any update and uses that snapshot for modifications. Since btrfs snapshots contain only the difference between two versions and thus are usually very small, updates done with transactional-update are very space efficient. This also means several snapshots can be installed at the same time without a problem.


Hi Timothée, thanks for clarifying those key differences. However, I’m intrigued as to why Fedora decided on rpm-ostree’s approach over a btrfs’ snapshot-based system like openSUSE’s. Were there specific technical reasons or use cases behind this? Open to insights from the community on this.

rpm-ostree works with any filesystem. Btrfs snapshots obviously require you to use Btrfs.

The main difference in the approach is that with rpm-ostree you have a pre-built image and you can thus see the difference between it and the local changes on your system. It’s easier to make sure that all your systems are running the same bits and have the same config.

The disadvantage is that you have to build those images and decide which packages should be included in them, or pick the ones that are built in Fedora and accept the choice of packages, whereas with transactional updates you can use any combination of RPMs.


To be honest, I am ok with that, the concept of layered packages works for me, the only challenge I haven’t overcome is WiFi broadcom driver for my old MacBook Pro. But that wouldn’t be an issue if I managed to find a laptop with preinstalled Silverblue, or at least make it work on linux-friendly model such as Dell XPS 13. Thanks for your insights!

You can find a list of Linux/Fedora friendly hardware here:

Some of the vendors allow you to choose the OS, the laptop is delivered
with. I’m not sure Silverblue is an option. But the hardware should work
well with Silverblue.

Aye, this is basically correct about transactional-update.

We are based on openSUSE Tumbleweed, which is a rolling release, and we get a fresh “image” basically every 24 hours (in a perfect world, sometimes theres a lag if we have something fail in openQA or elsewhere).

So there is no “fixed” base image in openSUSE Aeon/Kalpa/MicroOS. As @siosm said, that does mean we don’t have an easy way to compare what the user may have installed, versus the “pre-built” image like Silverblue/CoreOS do. We also don’t have the concept of layering, like Fedora does.

If you decide to install rpm’s that aren’t included in the base install, you’re quite literally modifying the base system, which is fine 99.9% of the time if you’re just pulling packages from Tumbleweeds official repositories. But it can become a broken mess if you’re the sort of user that really leans heavily on third-party repositories like RPMFusion or Packman. We leverage flatpak/flathub and distrobox to a greater extent than Silverblue/MicroOS do.

If you’ve got any specific questions, I’d be glad to answer them.


Yes, the git-like transparency over filesystem changes is the big stability advantage of rpm-ostree, not found anywhere else.

The A/B root in VanillaOS and other distros is similar to transactional-update afaik, in that it uses the regular package manager too.

The ability to reset, rebase, rollback, pin etc. is extremely useful.

Cases where one would like to

  • use a specific kernel (may work, may create dependency problems, probably not worse than regular Fedora)
  • use an entire arch with no image available (like risc-v atomic)

Are problematic or impossible on rpm-ostree.

The first two of those cases there are pretty easy on an rpm-ostree system. Just use sudo rpm-ostree override replace foo.rpm to replace any base layer package.

I’m not really sure what use case the third bullet point is describing so don’t know if I can speak to that one.

Aye, don’t have to get into building images, or any additional infrastructure or tooling, with the way we use btrfs snapshots and transactional-update with our stuff on openSUSE. Which can make it a bit more flexible than the image based setup of rpm-ostree I don’t honestly have any real opinion on whether either approach to the issue is “better” I just think they’re different.

I’ve not actually looked into VanillaOS, or the other offerings out there, but I believe they’re leveraging snapshots in a similar way that we do with the MicroOS based products.

Cool, I will have to experiment with that!

@sfaulken yes, no rating here. The one has more freedom and flexibility (and thus maybe also more sustainability), the other is simply image-based, with the pros and cons of that

The rebasing and reset features of the Fedora Atomic spins are neat, I gotta admit. And not something that is achieved nearly as easily with other systems.