Bluefin and Aurora Updates (KubeCon Edition)

Bluefin and Aurora
,
1

Greetings from Salt Lake City, USA! It’s a busy week (we have both Aurora and Bluefin releasing new major updates this week, stay tuned!)

  • Documentation - there have been lots of updates to the docs this cycle, make sure you check them out!

The team has been on a tear working on eliminating tech debt and issues. There will be more information in the release notes, but here are some of the major ticket items. Note that some of these have landed and some are in progress:

  • Bluefin and Aurora are now bootc enabled, ujust update and ujust rebase-helper will start utilizing bootc. Thanks to tulip for making this happen!
  • We’ll be adding a ujust switch-streams alias to the rebase helper since CoreOS calls them streams, this should help with consistent terminology
  • We’ve removed some responsibility from topgrade so it stops getting stuck on edge cases, it’ll only update the system components now.
  • The ephemeral Fedora and Ubuntu toolboxes are being removed.
  • We have begun the process of moving to a pure image based mode - this is currently off. In the future you’ll have to toggle a config file in order to enable local layering. The rpm-ostree tool will remain on the image but we will be constantly reassessing its removal. We’re targetting F42 for this.
  • m2 moved mountains and rewrote the entire build process. Everything you need is in the included justfiles, check the documentation for more info. This also decouples the build process from GitHub, making local development a breeze now. This is the most important improvement we’ve made, despite it being invisible to most of you since building Bluefin on your own kit is now pretty easy.
  • We’ll also be landing new changelogs, here’s Bazzite as an example - this will make it easier for you to follow along.
  • bsherman has slain the rest of the hardware acceleration issues - for now lol.
  • There has been significant progress on systemd-sysexts from around the OSS community recently, keep an ear out as this is progressing much faster than I was guessing. The Final Shape is coming.
  • Most of the work this cycle was getting the stable stream up and going. Don’t expect major user facing changes to Bluefin as we consider the project mostly complete and focus on the long term maintenance.

As always, file bugs if you see them! We don’t have a crystal ball for F42 but the big ticket items for us will probably be: Move to Fedora’s official bootc images, move to zstd:chunked for efficient downloads, and systemd-sysext integration.

See you in a few days when the new aurora:stable and bluefin:stable land!

34 Likes
2

Cant wait!
Nice Progress but Not too fancy! Love it

3

Gonna go ahead and enable lock layering ahead of time, so I don’t accidentally do something while being ‘drunk’ :woozy_face:. I’ve being doing fine so far even with ProtonVPN (I used the unofficial Flatpak, and it works really well).

1 Like
4

圖片
圖片1920×1065 121 KB

The fonts in the docs is too dark.

2 Likes
5

This was just merged and in hindsight some of the defaults have color contrast too low by WCAG AA accessibility standards.

Appreciate the feedback, will revisit the text palette. :pray:

2 Likes
6

If I understand correctly:

  1. From today to sprint 2025 layering will be enabled by default. Just like now, nothing changes.
  2. Since spring 2025 layering will be disabled by default. What about the users that have already layered some package? If disabling for those uses then some apps will stop working. I imagine this will be done for new users or some kind if-then-so logic to not disable for users that have layered packages.
  3. If we are “moving” to pure image then in the long term I suppose we are going to be “moved” (not emotionally but physically, joke…) and layering will not be possible at all, feature removed. This is good move from system stability and security point, but what about programs that requires root access (e.g. iotop program). Do we see on horizon some other new way of installing applications that requires root access, maybe some new technology not yet developed/finished? If I remember correctly I have seen some:
    “bootc dnf install <package>”
    or something, somewhere…
2 Likes
7

Yeah, I wonder this too.

I am a noob so I could misunderstood something but I think installing packages on atomic distro with completely locked root is exactly what systemd-sysext is all about. It provides possibility to install packages by creating extension to filesystem that is linked on runtime and independent from core system files.

8

According to this PR, you could still change that.

9

  1. You can still change it by editing the config. also when moving to bootc it should also tell users if they have layers, what to do to be able to update

  2. Guess we are waiting for systemd-sysext to materialize which then could be used to “layer” software

1 Like
10

I have now found it:

  • Fedora bootc: “Client-side logic currently in rpm-ostree will slowly be migrated to dnf.”

  • F41 Change Proposal:: “Additionally to DNF we will still provide rpm-ostree as the main tool for package layering on the client side and bootc to manage transactional, in-place operating system updates using OCI/Docker container images.”

11

For people using local packages (like myself), the Fedora and Red Hat devs are investigating how to handle layering on systems using bootc, which looks like it will likely involve a dnf plugin and local image builds: Local package layering story with bootc & dnf5 (#4) · Issues · fedora / bootc / Issue Tracker · GitLab

3 Likes
12

The preferred way going forward would be to use either Sysexts or DNF having image mode support in the future, see Add support for fetching RPMs from a registry · Issue #4155 · coreos/rpm-ostree · GitHub

13

image
image1209×907 87.4 KB

3 Likes