While we try to help people as much as we can, we prefer that issues are triaged through GitHub so they can be tracked and labelled properly. Here’s a quick guide.
If you’ve been redirected here it means one of us wants to track this in GitHub. Don’t worry, you didn’t mess up, we just need to put it in the system. This forum and GitHub support markdown formatting, so usually it’s just a matter of copying and pasting it into GitHub.
Read the GitHub Quickstart
Read this guide to contributing to Open Source
Quick tips
One issue per problem please!
Try to fill out the form as best you can
Remember we’re enthusiasts with jobs, sometimes it might take a while, especially if it’s a nice-to-have and not a critical issue
Setting Expectations
We’re Linux geeks, but most of us come from an ops background and not deep technical distribution work. More hands on deck are always welcome!
Kernel issues like freezes and crashes can be tough to diagnose, we’ll do our best
There’s not much we can do in certain situations, if you’re using an Nvidia closed source driver sometimes you might get an issue that is completely out of our control - the gift that keeps on giving!
Check Fedora’s How to File a Bug docs - please be respectful when reporting issues to Fedora - it doesn’t hurt to rule out a Universal Blue issue before reporting something for Fedora. Our intended mission is to help Fedora as efficiently as possible.
Some days the t-rex just gets you - If you’re treading off the beaten path it’s entirely possible that you are the first person trying it. Thanks for volunteering by filing issues and submitting documentation.
Finding where to file an issue
Depending on where you find an issue, it might need to go in a certain repository. Don’t worry if you mess this up, we can move them, here’s a quick guide to save you some time.
ublue-os/bluefin - Aurora and Bluefin build out of the same repo, file issues with those here.
If you have a Framework laptop file an issue in one of these, depending on what you’re using.
Universal Blue Repositories
ublue-os/config - for just commands, udev rules, and service units. Things in this repo end up on every Universal Blue image.
ublue-os/akmods - extra kernel modules. Usually for that awful piece of hardware that doesn’t have inkernel driver support.
ublue-os/main - for base images. Issues about codecs, and general issues. This is usually our catch all repo and will have issues relating to things that affect the entire project. These don’t integrate akmods so no weird hardware things don’t go in here.
ublue-os/hwe - hwe means “hardware enablement”. If you have an issue with Nvidia, Asus, or Surface devices, file it in this repo.
ublue-os/toolboxes - Anything related to our distroboxes and associated podman quadlets.
The thing that kicked off my reply here is that with the latest Bazzite update (to F43.20260303 from F43.20260217), my password manager, KeePassXC has essentially failed. The specifics of that aren’t important, but here are my Github reports:
and
The important bit is that both of those bug reports were almost immediately closed because each group said the problem was with the other group. Let me include one of my blurbs from one of those reports:
I’m not knowledgeable enough to track this down to whatever the root cause is (let alone fix it – I’m just a normal guy). So, how do things get fixed in Linux when it’s basically just a federation of programs on top of a kernel? This is a pretty serious problem (password manager no longer works) and I have no idea who else to let know about it. Again, there’s been no update to KeePassXC since 23 November 2025. This problem started when Bazzite updated 2 days ago. So, the implication is that something in that long F43.20260303 changelog broke something and I have no idea how to track it down.
I can almost understand KeePassXC closing my report as Not Planned. After all, nothing changed on their side of things and it was working before. But, I don’t understand why they did so without any checking that there wasn’t actually an underlying issue that didn’t surface until now because something way upstream (hello, Wayland) changed.
But, I’m flabbergasted by Bazzite’s immediately closing my issue there as Not Planned. I’m just a stupid user of a gaming distribution. I’m literally their target audience. The best I can do is say “you just changed something and this thing broke.” I’m not knowledgeable enough to track things past the obvious thing that broke and the thing that changed. Yes, I know correlation does not imply causation. But, that’s the best I can do and, as with KeePassXC, it didn’t get closed because they couldn’t reproduce it. It got closed because it looks like someone else’s application got broke. It’s not like I can somehow figure out how to go back to F43.20260217, pin it and wait for a fix. They closed the bug reports, so there won’t be a fix.
So, very literally and meaningfully, I’ve got to ask, how do we really report issues with problems? What, exactly, does Bazzite consider to be a problem that it would look at? How do I, as a mere gaming distribution user, know who to report anything to?
