Curious about this because it appears to cut out the middleman, and just seem a lot easier to maintain overall (maybe not, since there’s already a lot of ostree infrastructure, but who knows, that’s why I’m asking)
MicroOS just uses btrfs read-only filesystem trees instead of ostree and achieves what appears to be the exact same result. Since Fedora is trending towards using btrfs by default, is there any interest/movement through the steering team to make Silverblue, other ostree variants read-only btrfs?
It already does default to btrfs with /usr being btrfs mounted as ro by default and container storage being overlay with btrfs. This is also true for Kinoite (the only other generally available variant at the moment).
Ostree is like git for a file system. It has the concept of commits that allow for versioning and delta updates. I couldn’t find anything except issues on “btrfs read-only filesystem trees”, so I guess it’s just a partition/volume mounted in read-only mode. And so, I guess, these things already work together.
Currently, there is no plan to replace to “rpm-ostree”. Also I don’t wish to see that. Current rpm -ostree mechanizm has nice control over SB and other variants. It also gives you tools for the control it (for example core-os setups)
Silverblue and ostree go beyond just providing an immutable read only file system. It’s about reproducibility and provisioning via an image-based format.
Hey, sorry, I thought I had replied to this like a week ago but unfortunately rebooted my system before hitting send.
I’m going to paraphrase to see if I understand this correctly:
ostree and rpm-ostree apply filesystem or RPM-sized snapshots respectively much in the same way as tukit on MicroOS (formerly transactional-update), but can now detect if the underlying filesystem is btrfs or xfs/ext4 and use RO btrfs snapshots on btrfs filesystems, or OverlayFS if the target filesystem is non (or unsupported) CoW?
Or do {rpm-}ostree still always use OverlayFS (or some other fuse/squashfs type variant) even if the system’s running btrfs?
Yeah that’s a great post - he gets into a ton of tangential stuff. I’m kind of looking more for something he touches on in this post, too: On BTRFS « Colin Walters
But both of them are essentially talking around everything other than what I’m trying to figure out, which is, “what’s the difference between the way {rpm-}ostree does RO filesystem transactions on fedora using btrfs compared to tukit on microos (which has always used RO btrfs snapshots since inception, never overlayfs)”?
I will keep reading Colin’s page, maybe he gets into it somewhere else I just haven’t seen yet. Thank you
BTW I don’t think there’s anything different regarding reproducibility between tukit and ostree delivery systems, they are snapshots of filesystem or rpm sized deployments with hashes for each respective version, and can deliver full or delta versions. Unless there’s something I’m missing, it seems pretty straightforward.
But I’m more after the interaction with the filesystem - last I’d heard about it ostree only used overlayfs, so if it’s doing something btrfs specific now, that’s new to me (and awesome).
My understanding is that ostree simply uses read-only bind mounts. You can see something like this when running mount, where /usr is mounted as read-only.
/dev/sda3 on /usr type btrfs (ro,relatime,seclabel,compress=zstd:1,ssd,space_cache,subvolid=257,subvol=/root)
I don’t really think of ostree as “snapshots”; that’s probably not the best way to describe it. You’ve probably heard that it’s “like Git”. So think of them as “commits”, and a collection of commits make up “deployments”. As such, you can see the repo at /sysroot/ostree/repo.
You can see the different deployments at /sysroot/ostree/boot.0/fedora. At boot, you can see that your boot arguments contain a ostree= that selects one of these deployments. This basically does something like chroot into the deployment at boot time.
I found this article that might be helpful as well if you haven’t read it already.
Thanks for the /usr fs output, that’s really helpful and interesting.
You’re definitely more correct re: commits vs snapshots terminology. “Snapshot” is used a lot in the MicroOS materials, because I guess it’s closer to what they’re doing. Coming from OpenSUSE, they:
already had RO btrfs RPMs for packages delivered via zypper,
already had RO btrfs base images for OS installs (and containers, etc.)
create a RW snapshot of the entire / FS when using tukit, which then adds the RPMs to that mutable FS copy, then reboots into it RO when you’re done.
So I think it’s easier for them to make the rhetorical association with snapshots than ostree, since the ostree process is quite a bit more complicated to deal with layering rpm-ostree over ostree, and using lvm + ext4 + overlayfs instead of just btrfs (this would obviously be impossible on MicroOS since it was developed entirely around using RO btrfs).
Unfortunately, I still don’t really have an answer as to whether or not newer deployments of Silverblue still use OverlayFS for the rpm-ostree layer if they’re installed on btrfs, but would like to find out…
This was “traditionally” the behavior of rpm-ostree on XFS/EXT4 formatted drives, wasn’t it?
I’ve noticed there’s two sets of documents out there for rpm-ostree, and one is very outdated, but it’s not marked clearly that it’s deprecated, so I keep getting directed to it when googling for info and getting confused.
I also forgot to mention that overlayfs is also used when using apply-live.
I don’t know much about the history of rpm-ostree. But it was used in Fedora CoreOS which defaults to XFS before Silverblue was created and uses btrfs. As far as I know, rpm-ostree is fairly filesystem agnostic. I think the only filesystem features that it strictly requires are the ability to symlink and hardlink - features that are pretty widespread.
Edit: This may also be an interesting read, if you haven’t seen it already:
I don’t think the FCOS dudes and dudettes would agree. It is the evolution of it though, and likely the way Silverblue, Kionite will go, IoT is already pretty much the same.
Thanks!