Bazzite 45 is here!

[kylegospo]

What’s New & Improved

• Bazzite is now based on Fedora 45!
  • GNOME 51.1 and KDE 6.8.2
• Updated OGC kernels to 7.2.15 and 6.18.60 for NVIDIA LTS images.
• Mesa 26.2.6.
• Latest and greatest InputPlumber.
• Optional gaming networking optimization via bpftune and bpfrag services.
• ROCM OpenCL is now used over Mesa OpenCL on all non-nvidia images.
• XWaylandVideoBridge has been removed, fixing an entire class of bugs on our KDE images.
• Acer Predator Atlas 8 initial support: InputPlumber support, Quick Access Menu tap action, and M1/M2 rear-button mappings from (@HikariKnight. #6125, #6136, #6151)
• Ally X20 support lands on stable. Thanks to everyone who tested it out and reported issues in the leadup to launch. A fix for a reported custom TDP issue is still pending on our testing branch but will hit stable in the very near future.
• Logitech TrueForce wheel support: Additional racing wheels now supported out of the box.
• BTRFS maintenance now available from the BTRFS Assistant GUI. (@stellaberrant, #6134)
• ujust install-coolercontrol now uses the official docker container rather than layering packages. Existing users can run this again to switch or keep their layered copy indefinitely.
• extest, the library we rely on for Steam Input support under Wayland, now supports the 64-bit Beta Steam Client.
• Fixed GNOME Logo Menu translation compilation and restored welcome-screen accent colors. (@LDCanetti, #6193, #6189).
• Fixed occasionally concatenated tips. (@rktjump, #6041)
• Added Ukrainian translation (@andreysey #6201), updated Swedish translation (@yeager #6175), and synchronized other translations.
• FCITX5 input now uses the official Flatpaks rather than the out of date packages we previously shipped.
• And hundreds of tiny fixes and improvements, see the full changelog for more details here

Linux Anti-Cheat

Epic recently announced that their Easy Anti Cheat is getting a v2 launch on Linux that will bring support for Fortnite and other games! They were kind enough to make us one of the accepted well-known signing keys. Further discussions are underway, but in the meantime we’ve added a ujust readiness check for users that want to ensure they’re ready early.

• New readiness checker: ujust check-anticheat checks published Easy Anti-Cheat Linux v2 requirements and provides pass/fail results with tips to correct it’s findings. (@tapoxi, #6065)
  • Checks Kernel/module signing, Secure Boot and enrolled keys, TPM 2.0, measured boot, IOMMU requirements, kernel lockdown, kexec, and BPF LSM.
    • Handheld users should hold off from enabling kernel lockdown for the time being, we are working on a solution for this.

    • Steam Deck users must not enable Secure Boot, when this changes we’ll let you know.

Our biggest small update yet

With the launch of Bazzite 45, we’ve done a great deal to improve how Bazzite is built behind the scenes to make the lives of contributors and maintainers alike easier.

• @tapoxi spent a great deal of time retooling our build system to be simpler and easier to use for local builds, the full details of which can be found here.
• @SmallsOnline Split our monolithic containerfile into numerous different build scripts, enabling single-image builds and halving build times. Full details can be found here.
• @Andy10115 has been working diligently to improve testing and onboard new devices, details of their work this cycle can be found here.
• Vestigial files/packages have been cleaned out across the project.
• Image chunks are now all ZSTD compressed, enabling faster downloads.
• Chunkah is now in use and, when combined with greatly expanded rechunking and fixes to reproducibility during build image, have enabled Bazzite updates as low as 100MB in size.

What’s next

Starting today we’ll be testing Kernel 7.3.1 on our unstable branch. Our main focus is on HDMI 2.1/VRR and ensuring no surprise regressions after the rather rocky 7.2 series. You can switch to unstable and help test with brh rebase unstable, let us know what you think!

We’ll also be testing the latest version of steamos-manager on these builds, and a huge set of improvements to the Bazzite Portal.

If you’re one of the awesome people who helped with testing this cycle, you can now switch to stable Bazzite 45 using brh rebase stable.

Check out the posts below for more update detail!

[tapoxi]

Hi all, happy to contribute to Bazzite! I’ve been using it as my daily driver for the past ~2 years, and its fun to help out with something I use daily. Here’s what I worked on for Bazzite 45:

ujust check-anticheat

Epic has announced that it’s bringing Fortnite to Linux and rebuilding its anti-cheat as Easy Anti-Cheat Linux v2 with Fortnite as the first pilot before it opens up to other developers.

EAC has supported Linux for years, but many games never opted in because the Linux version couldn’t offer the same protection as the Windows one. To close that gap, v2 will require a set of security features Linux already has: a signed kernel and modules, TPM 2.0, Secure Boot and measured boot, IOMMU, kernel lockdown in integrity mode, kexec disabled, and BPF LSM.

To make sure your system is compatible, Bazzite 45 adds ujust check-anticheat, which runs through each of Epic’s requirements and prints a pass or fail, along with a hint on how to fix anything that failed.

It only reports, so it won’t change anything on your system, and any fixes, like kernel arguments, are yours to run. We’ll keep updating this once EACv2 goes live and is formally documented.

Build Process Updates

Behind the scenes, our image builds got a big cleanup. All the build logic that used to be scattered across workflow bash and helper scripts now lives in a single Python tool, build.py which CI and local builds both use.

• Run ./build.py doctor to make sure you have all the requirements to build Bazzite.
• Run ./build.py build to build the base Bazzite image. You can also pass in other image types, like bazzite-deck-nvidia, to build those instead.

Alongside work by @kylegospo and @SmallsOnline we were able to make various optimizations to the build pipeline!

• We stopped resetting timestamps on files that didn’t need it, which took a bazzite-deck-nvidia build from about 24 minutes to 14.5.
• SBOM generation now runs a couple of minutes faster, and spending some spare runner disk on speed saves about 3.5 minutes per image.
• The release job also went from about 5 minutes to 38 seconds by letting the release notes generation step parse a subset of the full SBOM.

All told, this means a CI run of Bazzite went from 50 minutes to 30 minutes, which helps fixes and improvements reach you faster!

[SmallsOnline]

Hey all, Smalls here! Happy release day!

The biggest amount of time I have spent with this update revolved around splitting up how our images are built. They’re not the flashiest of user-facing changes, but they are huge changes for current and any future contributors/maintainers going forward.

I wanted to give a bit of a detailed overview of those changes, so let’s get down to it.

Splitting up the monolithic Containerfile

At the heart of building Bazzite is a Containerfile that defines how the image is built. Before Bazzite 45, just about every package installation and customization was done directly in the Containerfile. Due to the nature of how they work, they can get unruly with a bunch of chained shell commands that are easy to mess up and make it harder to maintain. The best way I can describe what it looks like is if you’ve ever seen someone post a big one-liner command.

With Bazzite 45, we’ve gone from a single 800+ line Containerfile to just 102 lines. Everything in there is now split into modular shell scripts under build_files/ in our repository. Not only that, but they’re documented with inline comments to help us and others understand what’s actually being done and why. It also gives us the ability to run tools like shellcheck locally, as well as when pull requests are made, to catch bugs and other bad practices before they get merged.

This change has already helped us catch some old things that aren’t needed anymore. In the end, I believe it’ll help everyone out going forward and should make things a lot more portable.

Separate build stages, no more

In addition to splitting up the monolithic Containerfile and other efforts by @tapoxi, @kylegospo, @renner, and others, we’re now able to do everything in one build stage and have reduced the amount of time it takes to build the images. Bazzite offers many different image variant combos to suit user-preference and hardware. There are the desktop and handheld/HTPC variants, which both have separate images for GNOME and KDE desktop environments and separate Nvidia-specific images for each.

One of the most time-consuming steps in the image builds was transitioning from one build stage to the next. Especially for the Nvidia-specific images. We originally had the base desktop stage, then the deck (handheld/HTPC) stage, and then, finally, the nvidia stage. Not all of these stages are ran for every image, but for the ones that needed them they would spend a good chunk of time copying the contents of one build stage to the next.

With Bazzite 45, it’s all just done in one stage and the deck/nvidia-specific additions are now built conditionally with build arguments. When you factor in this change with all of the other build optimizations done this release, all ten of our images are now built, usually, within 30 minutes. Before it would take almost an hour, with the worst being nearly an hour and a half. That is a massive improvement.

Wrapping up

Even with the changes we’ve made on our end, there’s always something to do to make it even better. What I’m hoping with the Containerfile not being monolithic anymore is making it less daunting for others to help make improvements.

All that being said, enjoy the new release!

[Andy10115]

Hello to all our amazing users, testers, and contributors! Andy checking in!

Coming off the heels of Bazzite 44, this release might seem a little smaller in comparison, but don’t let that fool you. A tremendous amount of work has happened behind the scenes, including changes that will help keep Bazzite maintainable for years to come. Everyone has been incredibly busy, and many hands have helped make this release possible.

Improving Bazzite Through More Rigorous Testing

When I started working more closely with the team, one thing became very clear: Bazzite has grown tremendously over the last several years. We’re now at 103,000 weekly active devices, for those keeping score!

With that growth comes new challenges, particularly around how we identify issues, coordinate testing, and prepare releases. The processes that worked when Bazzite was a smaller project don’t necessarily scale to a community of this size.

That’s where I’ve been focusing much of my attention this release.

Coming from an IT support background, I know how important good communication, documentation, and issue tracking are to keeping things running smoothly. I wanted us to have a more structured approach to testing without losing the openness and community involvement that make Bazzite special.

And from those efforts, our new Bazzite Testing Program was born!

We’ve introduced several improvements:

• Public visibility into testing activities, because our community deserves to know what’s happening behind the scenes.

• Dedicated testing spaces in our Discord server, giving testers a place to coordinate, share findings, and work directly with the team.

• Required issue reporting through GitHub, ensuring problems are properly documented, tracked, and don’t get lost in Discord conversations.

• Better communication and coordination around testing activities, known issues, and upcoming releases.

• Dedicated roles and recognition for our testers, because the folks who consistently show up and help us chase down issues deserve some recognition for their efforts.

The goal is simple: catch more problems before they reach our stable releases.

Of course, we’re still growing this program, and there’s plenty of room for improvement. But we’ve already seen how valuable having a coordinated group of testers can be.

And we could always use more help!

If you’re interested in getting involved, come join us on Discord. You don’t need to be a developer or a Linux expert. We’ll help you get started, walk you through the process, and make sure you have the tools you need to contribute.

The more people we have testing and documenting issues, the fewer surprises we’ll have on release day.

A Big Thank You

I really can’t say thank you enough to everyone who has already answered the call.

Thanks to the folks who jumped in to help test the new ROG Ally X20, we were able to identify and resolve several issues very quickly. That kind of community involvement makes a real difference, especially when we’re working to support brand-new hardware.

Bazzite 45 testing also went incredibly smoothly, and I think that’s a great early indication that we’re moving in the right direction.

None of this works without people willing to volunteer their time, test builds, file reports, and occasionally break things so the rest of the community doesn’t have to.

To everyone who has helped, whether you’ve been here for years or just joined us recently, thank you.

I’m excited to see where we take this next!

[xarishark]

Hey everyone, Xarishark here! I wanted to share what I’ve been working on for Bazzite 45.

First of all, sorry for being a little quiet during Bazzite 44. I had some family matters that needed my attention, so I couldn’t be around as much as I would have liked.

But I’m back for Bazzite 45 with more energy than ever, and I’ve been working pretty much non-stop on improving Portal and building what comes next!

Small additions to the current Portal

I added controller support to the current Portal, including Steam’s keyboard in Gaming Mode, and worked on redraw fixes and reducing background controller polling to make it lighter.

A few other Bazzite improvements

Elsewhere in Bazzite, I added temporary SSH access for those times you only need a remote connection until the next restart, along with an OpenGamepadUI toggle to make enabling or disabling it easier.

I also tracked down a few bugs, including a Steam workaround that was preventing real system updates and leftover autologin settings after switching to a desktop image. I was especially happy to finally fix the bug that prevented some users from switching to Desktop Mode as it finally hit my HTPC too. An old Plasma Setup configuration file was being left behind after an upgrade, and cleaning it up restored switching between Gaming Mode and the desktop.

The future of Bazzite Portal

Most of my time, though, has gone into building the new Bazzite Portal and its Decky companion plugin.

The new Portal brings updates, tools, system information, system management, troubleshooting, and community resources together in one app, with room for future Bazzite-specific features as our needs grow. It has full controller support, including rebasing and rollbacks, and works in Gaming Mode.

It will soon arrive on the Testing branch, where it’ll spend plenty of time being thoroughly tested and polished so we can give everyone the best possible experience.

For now, here’s a look at the features it has so far!

Updates and notifications

For the first time, Portal has proper update status in the notification area:

You can see when Bazzite is updating, when a restart is ready, or when something needs your attention, without keeping the Portal window open. Clicking the icon brings you back to the app to check what’s happening.

In Bazzite Portal, you can track updates for Bazzite, Homebrew packages, and Flatpak apps, and read the Bazzite release notes. The update keeps running when you close the window, and you can return to it whenever you like.

There are several notification icon styles to choose from in Portal’s settings, so you can pick one that fits right in with the rest of your tray. Your carefully curated notification area can keep its tidy-tray certification.

System management

This is where you can look after your Bazzite installation, switch versions, or return to a previous working system when you need to. The aim is to make those tasks easier to understand and manage from the app.

Your familiar tools

The tools you already use are still accessible under Tools. We’re also reorganizing the sections to fit your version of Bazzite, so NVIDIA-specific actions, for example, only appear on the relevant images. You can also pin the tools you use most to the Home screen for quick access.

A Decky companion, too!

For those who prefer using Decky Loader, the companion plugin brings the essentials directly into Gaming Mode. You can update Bazzite and your apps, check progress and release notes, manage automatic updates on handheld/HTPC images, and add even the full Portal to your Steam library!

If you’d like to help make the new Portal available in your language, you can join the translation effort on Weblate.

Thanks for your patience while I was away, and to everyone helping test, report issues, and translate the new app. It’s good to be back.

Enjoy Bazzite 45!

[HikariKnight]

Greetings! I am HikariKnight.
Some of you might know me as a long time Bazzite maintainer, or as that guy helping people with advanced virtualization on Bazzite-dx or you know me from one of my very early and very cursed projects.

Acer Atlas 8 shenanigans

My work have mostly been condensed to working on the button mappings for the Acer Predator Atlas 8, with some very helpful guidance from the ShadowBlip team that maintains InputPlumber, the new handheld control stack we are using.

Initial probing of the buttons on the Atlas 8 revealed some funny stuff that you would expect coming from a handheld with custom buttons, like pressing or holding one of the extra buttons sends a keyboard event with the button F22 or some random DInput button like my favorite TRIGGER_HAPPY1.
However that was not the case with this handheld, I will mention some of the interesting ones.

• Pressing the Guide button to open the left steam menu would only send a button press event with hidraw data (so raw usb data) and never a button release event.
• Holding the Guide button will instead send a keyboard event where LeftMeta/LeftWin and TAB is pressed and released immediately, so clearly the button cannot be used for steam chords…
• Pressing (not holding) Guide, M1, M2 or sliding any of the trigger locks would freeze the inputs on the handheld until a sleep+wake cycle or reboot
  • However we noticed by accident that having anything read the hidraw device would prevent the inputs freezing, which led to the abomination that is #6125
• Pressing the QAM button would send a DInput event named ABS_MISC with a value of 0?
  • ABS_MISC is an axis (analog trigger) event, so yes this button thinks it is an analog trigger
• Sliding the trigger locks in and out of position sends hidraw events
  • I joked about making the system play a click or bow drawing sound when you slid them into the different positions.

Generic hidraw driver for InputPlumber

Pastaq from the ShadowBlip team suggested I could test out the unmerged Generic hidraw driver to implement all these weird buttons, since i did not know any RUST, and they did not have access to the handheld.

Kyle was nice enough to clean up the patch and add it to the InputPlumber package we use in Bazzite and this generic hidraw driver for InputPlumber is currently fueling the button support for the Atlas 8.

Guide for adding new devices in the future

Testing so far has shown that this generic hidraw driver works wonders and really raises the floor a lot for helping getting new devices basic input onboarded, once the driver is merged into upstream InpuPlumber, I will be working on a guide to teach new people how to get their device added.

What currently works

• All the controls work except tapping the Guide button (hold it instead to open the left steam menu)
• M1 and M2 are fully mappable and usable in Steam Input
• QAM tap and hold works
• For now, TDP control is available through SimpleDeckyTDP or Panel De Control

What is left to fix

However we cannot fix the Guide button tap (press and release) without a proper hid driver for the device and some kernel work, but this gets us most of the way there.

Sadly the gyro in the Atlas 8 has no Linux support yet.

I imagine we will enable the OpenGamepadUI overlay for the Atlas 8 very soon, so i would not go about making advanced custom Steam Input profiles for the controls yet, unless you don’t mind re-creating them.

VFIO cleanup

Since we moved the advanced virtualization to Bazzite-dx, there were some leftover quirks in ujust setup-virtualization that has been cleaned up and had some bugs fixed that came to my attention after stumbling upon a video from ItsRoji recording his journey of switching to Bazzite on youtube, followed by another user reporting the same issue shortly afterwards.
Seriously stumbling across these videos at random is very fun for me and it makes me happy seeing people utilize the extremely niche things i have added to Bazzite.

The ujust now also sets iommu=on instead of iommu=pt in order to comply with Epics EAC V2 for Linux, however i know from experience that iommu=on can cause some weird hardware to slow down boot up and shutdown of the host machine.

If you are affected by iommu=on slowing down your boot and shutdown in Bazzite-dx then open an issue on github or in our discord and tag me directly and i will make an ujust toggle for this, but hopefully this will not be neccessary.

That is all from me, enjoy Bazzite 45!

[kylegospo]

State of the project

This has been one of our best years for contributions and overall community engagement. Thank you all for being here and for helping to make Bazzite what it is.

And with all that said, that’s all for this update. See you folks again soon!

[yonni]

Thanks to all the contributors for another great release!

Maybe this is the wrong place to ask, but when I read the Anti-Cheat news and that secure boot is required, I got a question.

When I got my Steam Machine I immediately installed Bazzite on it and there was some difficulty installing it, because right after installing the device would not boot and show the message “MokManager is missing”. The workaround was to clear the CMOS after installing Bazzite (see this thread in the Bazzite Discord: Discord )

Is this because the Steam Machine does not support secure boot?

And while I’m here a different question (sorry I never found an answer for this):
Is it possible to get firmware updates for the Steam Machine via Bazzite?

Thank you to anyone who might be able to answer those questions!

[HikariKnight]

yes it probably is because steam machine does not support secure boot, we do not have a steam machine to confirm this ourselves but we know valve does not have any secure boot keys enrolled so enabling secure boot on you deck will brick the device since not even the bios firmware is signed (from the explanation i got as you can not even get to the bios to turn it back off) so you effectively brick your device…

for firmware updates, i know we support getting firmware updates for the steamdeck and it should not be different for the steam machine i believe