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.
Older AMD GPUs will now be detected properly. (Thanks Action Retro!)
Hybrid GPUs using Nvidia + AMD/Intel should be working better now.
Hardware setup should only retrieve GPU hardware information once.
Fixed the GNOME Steam Deck image power profile to have sensible defaults.
Deck services should now be disabled on generic devices on the Steam Deck images.
Added workaround from ChimeraOS for Gamescope crashing if Steam hasn't been launched prior to switching to Game Mode.
Oversteer should now work properly once installed from Bazzite Portal or through Just.
Fixed Boilr installer not working in some scenarios.
Flatpak lists are now in /usr so changes won't be removed.
The desktop auto-login service has been removed from desktop images, and enhanced on Steam Deck images to check that Steam has been updated prior to starting gamescope session.
The Team Fortress 2 tcmalloc fix now works when Team Fortress 2 is installed on a microSD.
Hide GRUB Menu option from Bazzite Portal has been removed from the desktop images since the focus has shifted to the Steam Deck images for home theater PC setups.
pulseaudio-utils has been added since some third-party applications depend on this.
Fixed missing icon for Lutris.
Fixed the xdg-desktop-portals bug that affected the file picker.
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.
Do nothing
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>
name: startingpoint
## 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
base-image: ghcr.io/ublue-os/silverblue-main
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
modules:
- type: files
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
repos:
# - https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%OS_VERSION%/atim-starship-fedora-%OS_VERSION%.repo
install:
# - micro
# - starship
remove:
- 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
install:
- 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-os-wallpapers
# - 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
scripts:
# this sets up the proper policy & signing files for signed images to work
- signing.sh
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:
After 192 days of development we'd like to introduce Bazzite 1.0! Bazzite is a custom image of Fedora 38 designed to being the best in Linux gaming to your PCs, including the Steam Deck:
KDE's Vapor Theme
Bazzite is built from ublue-os/main and ublue-os/nvidia using Fedora technology, which means expanded hardware support and built in drivers are included.
Steam Game Mode
Additionally, Bazzite adds the following features:
Distrobox preinstalled with automatic updates for created containers.
Automated duperemove services for reducing the disk space used by wine prefix contents.
System76-Scheduler preinstalled, providing automatic process priority tweaks to your focused application and keeping CPU time for background processes to a minimum.
Customized System76-Scheduler config with additional rules and CFS parameters from Linux-TKG.
Custom update system allows for the OS, Flatpaks, and Distrobox images to be updated directly from the Gamemode UI.
Built in support for Windows dual-boot thanks to Fedora's installation of GRUB being left intact.
Update break something? Easily roll back to the previous version of Bazzite thanks to rpm-ostree's rollback functionality. You can even select previous images at boot.
Steam and Lutris preinstalled on the image as layered packages.
Exclusively uses ZRAM by default with the option to switch back to a swap file and set a custom size if desired. (1GB by default)
BFQ I/O scheduler to prevent I/O starvation when installing games or during background duperemove processes.
TLS/SSL secured DNS and NTP by default. (This is a handheld PC you're likely to use on random public networks after all)
Applies SteamOS's kernel parameters and enables amd-pstate by default.
Default-disabled power-user features, including:
Service for low-risk undervolting of the Steam Deck via RyzenAdj, see ryzenadj.service and /etc/default/ryzenadj.
Service for limiting the max charge level of the battery, see batterylimit.service and /etc/default/batterylimit. (Works even when the device is off)
Built in support for display overclocking. For example, add GAMESCOPE_OVERRIDE_REFRESH_RATE=40,70 to /etc/environment.
Ability to switch back to X11 on the desktop if desired by editing /etc/default/desktop-wayland.
32GB RAM mod your Steam Deck? Enjoy double the maximum VRAM amount, automatically applied. (Can you share your soldering skills?)
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.
Bazzite is a community effort and wouldn't exist without everyone's support. Below are some of the people who've helped us along the way:
evlaV - For making Valve's code available and for being this person.
ChimeraOS - For gamescope-session and for valuable support along the way.
Jovian-NixOS - For supporting us with technical issues and for creating a similar project. Seriously, go check it out. It's our Nix-based cousin.
Steam Deck Homebrew - For choosing to support distributions other than SteamOS despite the extra work, and a special thanks to PartyWumpus for getting Decky Loader working with SELinux for us.
cyrv6737 - For the initial inspiration and the base that became bazzite-arch.
Universal Blue images have traditionally been signed by cosign so that you as a user can verify that the image you're booted into is the same one we make in GitHub.
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).
Thanks to the upstream efforts in rpm-ostree, we can now run fully signed images directly. In order to do this you need to rebase to a signed image:
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/kinoite-nvidia:38
And then reboot.
Check the images page for updated rebase commands for your system. You'll now be on a signed image and be good to go, rpm-ostree and skopeo will handle the rest.
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!
We've updated the documentation to refer to this new command. You can of course continue to run on an unsigned image, but we recommend getting that sigstore goodness all the way to your device.
If you're sad about the URL becoming more complex, don't worry, soon it'll look like this: bootc switch ghcr.io/ublue-os/kinoite-nvidia:38. We'll let you know when that day arrives.
A huge shoutout to the sigstore and Fedora communities for their guidance and support. This is an important milestone for Universal Blue, one more requirement for moving out of beta is out of the way!
Today we crossed one million image pulls. Though Kinoite continues to dominate the leaderboard, our steady march forward continues.
If you've been kicking the tyres on this next generation of linux desktop, we thank you! This means that we've had a million upgrades, which isn't a bad start!
Generally speaking things are pretty stable, the next major work item will be enabling F39 builds, which we'll do whenever RPMFusion starts to make builds.
Our images are now signed, we recommend moving to signed images as soon as you can!
No major obstacles to report, while we still consider these images beta they are proving to be quite robust!
You might want to check the current open issues to see how people are getting on.
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.
This work was patiently prototyped by @dhoell over the course of many months while juggling a busy school schedule. Thanks for your contribution David!
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.
