Bluefin stable stream is now based on Fedora 41

Today the Bluefin stable stream updated to Fedora 41. bluefin:stable is ready to go! If you’re looking for Aurora, check it out here.

Thanks to those of you who have been running this stream and giving us your feedback! This concludes four months of testing and we now consider this ready for wider consumption.

While Bluefin GTS holds the fort, Bluefin shifts into high gear a few weeks later. Here’s some background info on the release:

Wait, that looks the same, didn’t we just do one of these the other day? Let’s go into it!

This post will be more detailed because if you use bluefin:stable then you know how to Linux enough to know what you want, so you probably want to know where we’re going.

How to use it

The ISOs are being worked on so they are still based on F40. It shouldn’t be too long until they’re refreshed. Use the website image picker to make sure you download the right image. You’ll be upgraded to the right version on your first update.

bluefin:stable-daily is also available if you prefer daily builds instead of weekly builds. This is the one I personally run on my main PC. As always check the docs for how to rebase onto the Bluefin that vibes with you. These instructions will also work if you want to upgrade an existing installation.

History (What is this thing?)

Initially we only offered Bluefin GTS as the primary product. At the time it was the only one we could make because we were a smaller team. But as new team members came on board we yearned for a more up to date Fedora/GNOME experience and have been working to offer a fresher Bluefin.

We also monitor the pulls of Bluefin and noticed that many of you rebased to newer versions even though we don’t expose them on the website. So there is certainly some demand there. :smile:

Rationale (Why did we make this?)

This image follows the latest stable of Fedora, F41, but comes at a staged cadence by following the CoreOS release cycle instead of the Fedora Silverblue one. Let me explain:

Traditional distributions are typically classified as “rolling release” or “stable release”. These days we can just look at the entirety of Fedora as a big ole set of git branches. Our operating system images can be built from any and all variations of those branches. It’s both rolling and stable, it really depends on the git tag you pull from. Even if we’re not building every variation now, it’s certainly possible. Additionally the cloud native approach lets us source operating system content from anywhere, we get software from outside Fedora and integrate it in a manner that suits our use case.

So in many ways it moves from “releases” vs. “rolling” to, what version of that piece of software do we want right now? We can select and choose the indiviudal components.

CoreOS doesn’t follow Fedora’s traditional release process, it has a “rolling release”. stable, testing, and next. You consume CoreOS this way, but in the background they still move from Fedora 40 → 41, they just hide that from you when they are composing it.

So, Fedora is doing its traditional release thing, and the CoreOS team delivers rolling convenience tag that just makes the process invisible to the end user. That sounds awesome.

CoreOS is for servers though, so what we really yearned for was a “CoreOS desktop”. Three aggressiveness settings, and the focus on automation to make all that “Just Work”.

So we talked about it

I discussed this with Fedora maintainer Timothée Ravier, whose base images have been the foundation of our project since the beginning. Of course they’ve had the same idea, it’d be amazing!

What I really want is to rebuild Fedora Silverblue and Kinoite fresh on top of CoreOS. But it’d be a bunch of work. And in order to make that happen we’d need to prove people want it, so that people would be encouraged to help make it happen.

So we faked it

bluefin:stable is an approximation of what a CoreOS desktop would look like, it’s a rolling tag following the CoreOS rolling schedule. We get the kernel versions and userspace that CoreOS is using and then build bluefin:stable and aurora:stable. We publish these tags on a weekly schedule, along with bluefin:stable-daily and aurora:stable-daily if you prefer a daily build.

Seriously we skopeo inspect the CoreOS container in the GitHub action every day and then pass that as arguments as part of the build process. The entire thing is automated to build based on what they publish. The brand new changelogs (thanks Antheas and m2!) will keep you informed of what’s coming in.

This means things land in Fedora proper first and then trickle down. The major release is approximately a few weeks after the Fedora release, and also gives us a gated kernel, so it’s almost as aggressive as bluefin:latest but with a little bit of extra padding. This helps avoid the occasional regression like this netfilter issue breaking Tailscale in 6.11.4.

We will remain on 6.11.3 thanks to Universal Blue’s kernel-cache. We’re keeping an eye on this one, your feedback helps us make better decisions. The cloud native model gives us another saving throw. :smile:

Here’s the lay of the land:

We feel it hits a great sweet spot for a “core operating system”, specially for enthusiasts who want the latest goodies. Our workloads are containerized, so we always get the versions of the software that we want.

We hope you enjoy this release!

16 Likes

This release is a great example of how valuable this setup is. Being able to move forward without introducing known bugs demonstrates its flexibility. It is truly awesome.

Thank you, everyone, for your hard work in making this possible!

5 Likes

Thank YOU for sending in pull requests! The flock grows. :smiling_imp:

2 Likes

Hey folks!

I just updated to the latest version of bluefin-dx-nvidia:stable

A thing, though :

Wasn’t dnf supposed to be an alias to dnf5 now (Changes/SwitchToDnf5 - Fedora Project Wiki) ?

malix@malix-pc ~> which dnf
/usr/bin/dnf
malix@malix-pc ~> which dnf5
/usr/bin/dnf5

Also, dnf5 doesn’t seem to work properly :

malix@malix-pc ~ > sudo dnf5 remove google-chrome-beta
Package                                             Arch         Version                                              Repository                        Size
Removing:
 google-chrome-beta                                 x86_64       131.0.6778.33-1                                      <unknown>                    348.4 MiB

Transaction Summary:
 Removing:           1 package

Is this ok [y/N]: y

Running transaction
Failed to open database "/usr/lib/sysimage/libdnf5/transaction_history.sqlite": (14) - unable to open database file
malix@malix-pc ~ [1]> 

Would not notice the update of not the accent color changed to gray?!
Is that on purpose? Not blue :thinking:

Very smooth!

You can change that in settings → appearance → style

Maybe related ?

https://fedoraproject.org/wiki/Changes/DNFAndBootcInImageModeFedora

Is there any advantage to rebasing to bluefin-dx from bazzite? (noting the need to clear out dot files possibly)

99% of my time is spent doing dev type work on my linux machine but holding out hope for friction free gaming if I ever find the time.

dnf is for us in container builds, not for end user usage unless you’re in a distrobox or something.

As much as I would like to not use dnf / dnf5, I still need layering for web browsers

Why is layering needed for browsers? I haven’t met problems with brave and firefox as flatpaks. Besides, I would use distrobox to install a browser if I really want to avoid flatpaks.

1 Like

Use rpm-ostree like you have been, nothing changes.

1 Like

I did with PWAs and screen sharing, specifically

Anyway, I do not want to hijack this post about it :smile:

2 Likes

we currently have cliwrap enabled meaning that the dnf you see at /usr/bin/dnf is actually an alternate call to rpm-ostree.

This is in the process of being deprecated and we haven’t removed cliwrap yet. This will occur as we switch to building with bootc in mind.

1 Like