After some hard work by our team members we were able to generate F39 builds of our images. Of course they are not stable yet, but if you feel the need you can already try them out. While working on this, we also introduced the gts tag which will enable you to cruise along on a steady stable pace. It will have your image follow along the latest-1 release. So you will have a rock solid machine. We currently pushing our free builders to the max with 57 images being generated. We hope you enjoy it as much as we do.
Type "just" in a host terminal to see a list of custom convenience commands.
Welcome to Bazzite Buzz #3! Bazzite is a custom image of Fedora 38 designed to bring the best in Linux gaming to your PC and handheld devices. This newsletter highlights all the work we are working on over the past few weeks. If you are new to a Universal Blue project here's some back filler: These images follow the continuous delivery methodology of development. That means we're constantly adding new things, so let's get started!
IMPORTANT: Nvidia GPU users should recreate the bazzite-arch Distrobox container. Open a host terminal and enter: just install-bazzite-arch to do this. The issue stemmed from missing 32-bit libraries that require the user to remake the container. As a result of this, it unfortunately means this fix requires manual intervention.
New hardware support and a ton of general fixes have been the main focus over the last couple of weeks for Bazzite. Some notable features added were the inclusion of a new system resource monitor application and adding proper support for Microsoft Surface devices. We also were committed to fixing as many issues reported as we possibly can, and tidying up the project as usual.
A modern task manager.
As time goes on, we plan to release an image dedicated to the Asus ROG Ally. This device needs a specific kernel and some other tweaks to have Bazzite function correctly on it. Discussion on this can be found here, and for progress on general handheld controls take a look here.
Hippie Hacker has created this guide to get iimatey working on a Steam Deck installation of Bazzite for a command line approach to installing it. This may solve issues with the current GUI installer or for those who prefer this command line interface method for installation.
Finally, most of the new features from the SteamOS 3.5 preview are already available in the Bazzite Steam Deck images right now. This includes gamescope's new scaling and color options. We also are already using newer base packages than SteamOS 3.5.
New Gamescope improvements on the Steam Deck images.
Bazzite has hit over 1,000 commits in a little over 200 days since the project's inception! We now own the domains bazzite.gg and metrics.bazzite.gg for this project. Offline ISOs are mostly ready to go, check it out below!
All hail the cube.
Before we move on to the changes we've got a new installation video from Justin Garrison
This post was edited on 2023-09-09 to change some inaccurate details. The PR has now been merged.
Startingpoint, the 'template' repository for creating custom images that includes a simplified configuration format recipe.yml, has been going through a rewrite for almost a month now. The rewrite is going to be merged as soon as it and the documentation is ready and tested, and this post will guide you through the changes.
The rewrite brings startingpoint from a single build.sh where incrementally added features were piled up, to a collection of modules run by a very simple build script in the order specified in the recipe.yml configuration. This fundamental change makes startingpoint more extensible and customizable, allowing you to add and remove features as you please. It also allows for sharing of certain configuration, such as packages lists, between multiple images built in the same repository.
Unfortunately, breaking changes have been made to the configuration (recipe) and the script system.
For maintainers of custom images, there are a couple of ways to deal with this.
Create a new repository and port your changes
This approach will be easiest if you are not that familiar with git and your changes are small.
This approach has the advantage that you can keep using your old repository while porting all of your changes to the new one.
If your old repository is a fork of startingpoint, you might want to detach it from startingpoint. This would allow you to fork startingpoint again to create your new repository (GitHub allows only one fork per-repo per-account).
Do a manual merge of the rewrite into your repository
You'll need to be familiar with using some software that allows you to do manual git merges. You want to accept all incoming files that are not configuration files, and manually figure out the configuration files.
This approach has the advantage of keeping your git history, and allowing you to easily move all your custom scripts into the new build at once.
Perhaps you've got a great custom build system going, you've done a lot of changes to build.sh, you've added new features you need. Or you just can't be bothered? Cool! You don't need to keep up-to-date with the startingpoint template if you don't want to. You'll still get OS updates, your current setup won't break. You just won't be able to take advantage of new features that might get added to startingpoint.
## image will be published to ghcr.io/<user>/<name>
## description will be included in the image's metadata
description: A starting point for further customization of uBlue images. Make your own! https://ublue.it/making-your-own/
## the base image to build on top of (FROM) and the version tag to use
image-version: 38 # latest is also supported if you want new updates ASAP
## list of modules, executed in order
## you can include multiple instances of the same module
- type: files
- usr: /usr # copy static configurations
# configuration you wish to end up in /etc/ on the booted system should be
# added into /usr/etc/ as that is the proper "distro" config directory on ostree
# read more in the files module's README
- type: rpm-ostree
# - https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%OS_VERSION%/atim-starship-fedora-%OS_VERSION%.repo
# - micro
# - starship
- firefox # default firefox removed in favor of flatpak
- firefox-langpacks # langpacks needs to also be removed to prevent dependency problems
- type: bling # configure what to pull in from ublue-os/bling
- fonts # selection of common good free fonts
- justfiles # add "!include /usr/share/ublue-os/just/bling.just"
# in your custom.just (added by default) or local justfile
- nix-installer # shell shortcuts for determinate system's nix installers
# - ublue-update # https://github.com/ublue-os/ublue-update
# - dconf-update-service # a service unit that updates the dconf db on boot
# - devpod # https://devpod.sh/ as an rpm
- type: yafti # if included, yafti and it's dependencies (pip & libadwaita)
# will be installed and set up
custom-flatpaks: # this section is optional
# - Celluloid: io.github.celluloid_player.Celluloid
# - Krita: org.kde.krita
- type: script
# this sets up the proper policy & signing files for signed images to work
You'll see that instead of top-level configuration keys like rpm: or firstboot:, there's one top-level array modules: that includes most of the previous configuration as modules. Modules are scripts, executed in the specified order, that take in yaml configuration from the recipe. Anyone can create a module by just putting a script in a subdirectory the modules/ directory. You can remove modules by just removing the entry in the modules: array, you can include multiple of the same type of module, and you can even share modules between recipes (images) using the - from-file: example.yml syntax.
This modular system changes the role of scripts a little. Scripts are no longer intended to read recipe.yml, instead they do a single (or a collection of) commands that are not intended to be configurable in the recipe. If you want to create a script that takes in configuration, create a module. Furthermore, scripts in the pre/ and post/ directories will no longer be executed by default, as there is no set "pre" and "post" phase with the modular system.
As a minor change, all user configuration has been moved into the config/ directory in the root of the repository. This might make manual merging from the old version a bit more convoluted, but should ease merges in the future.
When it is fully ready, tested, and documentation changes have been PRd onto the documentation website. A while after the merge there'll be a more newcomer-friendly announcement post. The new version will be considered a '1.0', and the amount of breaking changes will be kept as zero for as long as possible.
To quicken or effect the process, feel free to give comments, read through, and help in testing the PR.
For post-release I have plans for a PR that would allow the configuration of multiple modules be included using the from-file: syntax, a PR that would allow an entire directory full of build scripts to be run at once, without having to specify each one individually, and a blog post that would showcase high-level technical details of the repository without needing to get in the weeds by reading source code.
Technically, it would also be possible to "reverse" the flow by "compiling" the recipe.yml into a Containerfile, which is something I'm interested in exploring.
Bazite 1.0 released last week, but the hum of progress continues! Welcome to the Bazzite Buzz, our newsletter for all the good things we hope to bring gamers over the next few months. If you are new to a Universal Blue project here's some back filler: These images follow the continuous delivery methodology of development.
We build on top of the Fedora base and then build our customizations on top every day and on every change. That means when we fix something or add a new feature everyone gets it. So if we fix one of your issues it can be in your device in less than 15 minutes, and usually faster. Neat. The more people help out, the greater the pace of features and goodies.
In order to help with that we'll start publishing these Bazzite notes regularly so you can keep pace with what's happening. Here's a great tour video from Hi-Tech Lo-Life showing off some Bazzite features.
Every issue we will go over some of the most exciting changes, and we'll always link to the Bazzite commits so you can inspect them for yourself. Ok let's get rolling:
The installation process is still considered incomplete, we're hoping to eventually migrate to the new webui-based Anaconda installer which will be much nicer for our use case.
Like all Universal Blue images, Bazzite is using features that are on their way to Fedora, and are currently not considered stable. However with over 1.5 million image pulls over the last 9 months, we feel the model and method are proving to be reliable!
Download sizes are also currently less efficient than they should be. We're hoping that gamer interest in Fedora will bring in new ideas and contributors to help solve these issues.
When you rebase to a Universal Blue image, you might have noticed something:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/kinoite-nvidia:38
The ostree-unverified-registry section is something that we've had to use because we didn't have a way to run a signed image. You had to manually check the signature that we provide with cosign (as listed above).
The policies in stock Fedora don't support migrating to a signed Universal Blue image directly. For now we're recommending to rebase to an unsigned image first to get the right policies and keys in place, and then rebasing using the ostree-image-signed:docker:// snippet. If you have any ideas on how to make this smoother feel free to open a PR or file an issue!
And a quick call for help -- we're still in dire need of a more reliable ISO installation experience. If you are familiar with Anaconda we could use a hand, especially if you want to help bring the fancy new installer to our custom images.
Though this project may seem new, the first commit on this journey is a little bit over two years old! At the time "ublue" was just an imperative script.
Later that year, in November 2021, the first edition of what became the OSTree Native Containers spec was committed to the Fedora wiki. This flipped the project on it's head and the rest is history! Continuously delivered OCI goodness is here!
We've picked July 21st as our birthday since it's coming up (and we also forgot). So today we're celebrating two years of cloud-native goodness, thanks for hanging out with us!
Since early in the Universal Blue project, our Nvidia repository has been building kernel modules(akmods), though only Nvidia drivers. While this approach worked great at first, it became apparent that the akmods would need to be split off into it's own layer:
This kicked off a nice community discussion where the team figured out an approach.
First we needed to migrate to a new signing key and then begin splitting the akmods into its own repository. Conveniently, this also allows us to include things like v4l2loopback so that Universal Blue users will have that working out of the box. Soon we hope to add more hardware enablement akmods like XBox Wireless controllers, OpenRazer, and some older Broadcom wireless drivers.
As part of our move to beta we've found a scaling issue that needs to be sorted; skip below if you just want the instructions.
Initially the Nvidia images were signed by a key scoped only to the ublue-os/nvidia repository. At the time, we didn't expect to grow much past that, but now we want to add more akmods (like OBS loopback camera, XBox Wireless Controllers, etc.) which we are building in a seperate ublue-os/akmods repository as a "new layer" if you will.
As part of our secrets management process, we are regenerating the keys used for Secure Boot signing our kernel modules. This means existing users must install a new key for all of Universal Blue akmods in addition to the key specific to Nvidia.
On June 17th, we will switch Secure Boot signing to use the new key; from that time on only the new new key will be required.
As of this morning the new key is on the images, so subsequent new installations will be fine.