Bluefin and Aurora 3.0

Bluefin and Aurora
, ,
1

Jorge_CustomChonks_Roaring
Jorge_CustomChonks_Roaring1296×1296 171 KB

Introduction

First time here? Check out the Introduction to Bluefin. As we close in on our three year birthday we’re proud to announce a midsummer roll up update to Bluefin and Aurora that should hit the spot.

Bluefin | projectbluefin.io

image
image1281×805 64.6 KB

Aurora | getaurora.dev

image
image1275×802 36.5 KB

Release Overview

This started off as a maintenance release but we really found some pace over the past week so we’ve decided it was worth the version bump to 3.0. Special shoutout to M2 who did most of the heavy lifting on this one.

Major upstream updates include:

Not many surprises here, just a steady set of incremental improvements since the release of Fedora 40. If you’re already using Bluefin and/or Aurora then you don’t need to do anything special as updates are automated.

We’ve do have some new goodies we’d like to go over!

New Release Channels

Bluefin and Aurora now have a stable image, that will follow the latest Fedora release but with a gated kernel (see below). We feel like this hits a sweet spot for users who want to be on the latest version of Fedora but want a bit of a safety blanket. This is especially nice now that Fedora 40 has taken a few laps and is feeling really nice.

The team believes that this channel will be a favorite among enthusiasts. Here’s how it maps out:

image
image784×353 17 KB

Check the Administrator’s guide for more details if you want to rebase, and here are the ISOs if you wanna start fresh. The websites haven’t been updated yet so here’s the direct links:

Bluefin

Aurora

Asus and Surface users should stay on the latest channel. Aurora GTS was being published but is now disabled. We never publicized this and it’s the old Plasma 5 desktop so we’ve gone ahead and removed it.

The major difference between latest and stable is when they upgrade. latest will upgrade to the next major Fedora release as soon as it is available and it builds daily. stable will upgrade when CoreOS does it’s userpace upgrade, which is usually a few weeks afterwards, and only builds weekly.

How to try them

Use the ujust rebase-helper command to select rebase and select a specific channel:

image
image711×318 39.3 KB

Switching to Weekly Builds

Bluefin and Aurora will now publish a build once a week. This is to cut down on bandwidth consumption and to move to a more predictable model for development. (See below for more bandwidth news)

Your device will continue to check for a new update every day. If there’s an important security update we can publish a new image on demand. Therefore we strongly encourage leaving the default update schedule in place. Flatpak applications will continue to update twice a day.

Note that the latest channel will continue to build daily, if you want to stay aggressive then this is the channel for you.

Gated Kernels

Bluefin and Aurora now follow the Fedora CoreOS kernel cadence, and will be shipping the same kernel version as the stable CoreOS channel.

See this previous discussion for more context. Note that the latest channel will continue to use the upstream Fedora Silverblue kernel.

OpenZFS is now included (Beta)

The gts and stable channels now build the OpenZFS kernel module. Due to the nature of Linux kernel development and quick pace of Fedora’s kernel cycle, and it is not enabled in the latest channel or any of the hardware enablement kernels (surface and asus).

This will be in beta for a while and we only recommend it for advanced users for systems that are not used in production. We’re still unsure how this will work in practice as there’s usually a delay of when OpenZFS gets ported to a new Linux kernel. If you use this then thank you for volunteering to gather data. :smile:

Future Work

  • P5 is currently working on implementing zstd:chunked pushes for our images. This, along with switching to a weekly image build, will lead to less bandwidth consumption. We consider this feature to be our final boss. :smile: Note that we are preparing our publishing pipeline for this, we’re expecting this to be ready when Fedora 41 releases. We’ll also be using this on all our toolbox images when GitHub’s Ubuntu runners update to 24.04, which will likely happen soon.

  • M2 is investigating switching to an fsync kernel (the same one Bazzite uses) so that Asus and Surface users can just run on stock images. This will also be gated in gts and stable. Investigation into this is just starting so expect more details later.

Full Changelog

Yep, it’s short, most of this week was CI work. Just how we like it!

3.0.0 (2024-07-01)

Features

Bug Fixes

Miscellaneous Chores

Soundtrack

And most importantly, I’ve put together a new playlist for this release, enjoy the music!

20 Likes
2

Any idea on when Aurora will no longer be considered beta? Is there something we are specifically waiting to implement or are we just giving it more time?

1 Like
3

Switched the download links on https://getaurora.dev to the new stable ISOs now :star_struck:

3 Likes
4

Thanks for the update!

I managed to rebase my Aurora to stable, been using it for a couple of weeks on my daily (minipc) and find it is working really well!

5

Time mostly. While it shares most of its bones with bluefin, the plasma specific customizations were new this cycle.

Additionally, Plasma 6 is still going through its initial growing pains.

We have decided to deprecate the GTS version of Aurora. We will likely aim for stable to be the main version for Aurora.

That said, while it’s in beta it is perfectly usable and we do need eyes on it and people reporting issues.

3 Likes
6

I like having the updates only apply once a week for the image, it is a lot to keep downloading.

2 Likes
7

We’re seeing some positive gains from antheas’ work on rechunking the images so they should slim down in general too so that should help a bunch too.

3 Likes
8

I am really looking forward to systemd-sysext as well. If Bazzite, Bluefin and Aurora can just use systemd-sysext to layer on the developer experience stuff, I am all for that.

2 Likes
9

This might be a stupid question, but how will I now, which version is currently running?

I have installed Kinoite 40 a couple of weeks ago and rebased to Aurora later on. I am not sure if the automatic updates are actually working. :see_no_evil:

10

rpm-ostree status will show you the image you are currently on

image
image1012×308 32 KB

11

I like this strategy. Is there a particular day in the week where we should expect the non-security image update? Or is the schedule dynamically adjusted when there has been a security image update?

12

It’s sunday nights for gts and tuesdays for stable right now. ISOs update on the same run too so those will always be fresh.

1 Like
13

You’ll need to follow these instructions and then you’ll be on 2024-07-02 in your status that stego mentioned:

Also we’ll do a build whenever Fedora publishes the openssh-server update that was published this week, so there’s at least one more coming up.

1 Like
14

Thanks for the information!

I am now here:

$ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:latest
                   Digest: sha256:d21d17c7347ae2129c6ffbfaebfea54be66dde94a6783f7c42f004acf2565c61
                  Version: 40.20240703.0 (2024-07-03T04:53:17Z)

But in the first post it says something about version 3.0.0. Where can I find this version number?

1 Like
15

Oh that’s not exposed in that tool, I’ll add a thing to announcements from now on on checking the version number so that it’s clearer to check what version you’re on. You’re on the correct image!

7 Likes
16

Very happy to hear about that, since it would also allow Lenovo Legion to have custom patches

Two other notable info about, from @m2Giles :

it includes the surface/Asus patches as well

Fsync has all of the akmods built in ublue-os/akmods as well

17

aurora-dx-nvidia:latest is still stuck on 2024-07-02 name image as of tonight even after the key update, it doesn’t look like it is updating daily.

https://github.com/ublue-os/bluefin/pkgs/container/aurora-dx-nvidia

❯ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 23h ago
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia:latest (index: 0)
Digest: sha256:887bf42d1e0c06caac59e24c393202559243bafbc2a4f7ad63b64ca2e62a4f3e
Version: 40.20240702.0 (2024-07-03T04:52:41Z)
Commit: 00f78a22113bd435c7c2cc0aee14a715fa0818634a89845ecf0003a47aff5ab3
Staged: no
StateRoot: default

❯ rpm-ostree upgrade
note: automatic updates (stage) are enabled
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx-nvidia:latest
No upgrade available.

18

Have you actually done the needed steps to get back on the update train?

19

Yes if you look at the Github link the server build image hasn’t been updated. The aurora-dx one has been but not the aurora-dx-nvidia one.

20

Hey @j0rge , that’s why everyone is still stuck or getting back to Windows.
Too much confusion over different Linux OSes, Flavors and DEs.
Why is ublue trying to follow the same failing cycle?
If you want to move ChromeOS/Windows/Mac users to ublue:

  • Keep Bluefin and Aurora - users to decide if they want Windows or Mac look
  • There should be only one, 100% stable, fully maintenance-free ISO for Bluefin and Aurora
  • Keep system updates monthly
  • Keep application updates weekly