I agree with this sentiment 100%, but I think it lacks some of the context that these are children we are talking about. They aren’t being educated on privacy or security; not by their schools, and certainly not by their parents. This generation is being raised to believe that everything they do and say needs to be posted online to social media, and their concept of privacy is virtually nonexistent. Couple that with the fact that most of them don’t have a personal computer, and it leads to great levels of negligence with regard to their use of technology, and most relevant to this discussion, their use of school computers. The children being surveiled and exploited by this software don’t have the education on it to understand why it is bad, or even that it is happening to begin with.

So while yes, they shouldn’t have private communications on school computers, they don’t have the context to understand that or independently come to that conclusion themselves, thus those private communications will happen nonetheless.

No, here is the official RPMFusion documentation for it, which is linked to in the Nvidia driver documentation from RPMFusion.

Matrix leaks tons of metadata, and its encryption lacks perfect forward secrecy. Additionally, it requires an email to sign up, and there are accounts with unique identifiers.

Simplex does not have any accounts or identifiers, everything is stored entirely locally. Additionally, it is based on the double ratchet Signal protocol, with improvements made for post-quantum encryption. It does not require anything to sign up, as there are no accounts. Metadata is not leaked as it is with Matrix, as everything is encrypted or obscured. Messages are padded to 16KB, the sender/receiver is not attached to the message, and there are fake messages being sent to obscure the identity and frequency of contact of those you are talking to even under monitoring of your network. Additionally, for anonymity, SimpleX is allowing for repudiation so that you cannot prove that a specific person sent specific messages, allowing doubt if messages were to be use in a court case, for instance. It is the trend (especially from a security perspective) to implement nonrepudiation, but the SimpleX team decided to remove it to protect users (after years of it being present in SimpleX chat). This is a protection intended for journalists, but it extends to many other cases as well.

Matrix is a nice toy, but SimpleX chat is built for anonymity above all else, and it does that job far better than Matrix ever has or will.

Do you not consider Alpine Linux to fall into the general category of “Linux”, then? It lacks GNU user space utilities, though there is never a world where I would not consider it a “Linux” operating system. You seem to be overgeneralizing here and making assumptions about OP’s intentions that aren’t based in fact. I don’t see the point in drawing meaningless lines, here. What you’re referring to (as described by the GNU project) is GNU/Linux, not “Linux” by itself. The two are often but not always used interchangeably, and treating them as exactly the same leads to major outliers, like Alpine. I’ve heard plenty of people use the term “Linux” in practice to describe software running on embedded devices that don’t contain GNU utilities, so this isn’t exclusive to Alpine. In fact, the only real exception that I see consistently to operating systems that run the Linux kernel is Android, so it makes much more sense to formulate a description of the generic term “Linux” as simply having an exception for Android, though I’d argue that the only reasons that Android isn’t viewed as “Linux” is because it is a mobile operating system, it is developed with the sole intention of including non-free, proprietary software (AOSP by itself isn’t meant to be the full operating system on any device, but rather a framework), and the fact that the structure of the filesystem and the way apps are run differ completely from the ways of traditional “Linux”. It seems to be an exception purely by the fact that it operates in fundamentally different ways than other “Linux” operating systems.

Fedora is what I’d describe as cutting edge, but not bleeding edge. It’s still behind from source, and is semi-rolling release, so it’s further behind than Arch but way ahead of stable/fixed release distros like Debian

Shouldn’t be too long left, I’d expect it to hit Fedora 40 sometime this month. I also shared instructions on how to temporarily upgrade the kernel to the one in Fedora 41’s repos (which is past 6.9) if you were interested in trying that, though the instructions are untested as of yet (the issue doesn’t affect me since I don’t play games). It’s easily revertible if you wanted to give it a try. I probably wouldn’t bother if you use secure boot, because I’ve had issues with signing things before with similar steps, though those are the official steps from the Fedora documentation, so it may be that they just work fine.

Is it related to the issue described in the post attached to this comment? The linked comment also links to an issue page with details about the issue the poster experienced. If so, then that issue should actually be fixed in kernel 6.9 (which still has not been added to the Fedora 40 repos), and not caused by it.

An extension of this issue is present in 6.8.9+ before 6.9, which is why I ask if this seems to be related (since the versions are pretty close in time and Fedora doesn’t even have 6.9 yet).

Oh, that should be no worry. You can always do a clean install of one distro over another. Just make sure in the setup that when you select your data partitions on your other drives that you don’t remake the partitions (at that would delete them). You’ll also have to deal with differences in config files in your home directory since there is variance between Nobara and Bazzite. You can just grab the ISO and install normally, deleting the Nobara partitions.

The partition manager should be KDE Partition Manager on the KDE Bazzite, and Disks on the GNOME Bazzite (I don’t think GParted is installed by default)

Hey, I wrote a script for you since this was a really simple operation. I have 2 versions depending on what you want them to do.

I recommend that you make a test folder with a bunch of test directories and subdirectories to make sure this works as expected on your machine.

The first will only rename folders with a depth of 1 (meaning it won’t rename subdirectories). This is for if you want to control which specific directories you run this on.

Non-subdirectory version

#!/bin/bash

find . -maxdepth 1 -type d -name "_*" | while read FOLDER; do
    newfolder="$(echo ${FOLDER} | sed -e 's/^\.\/___/a/' | sed -e 's/^\.\/__/b/' | sed -e 's/^\.\/_/c/')" ;
    mv "${FOLDER}" "${newfolder}" ;
done

The second renames all folders including subdirectories (it goes 1 layer deeper at a time). So if you want to just run this from your home directory (or wherever the drive you want to run it on is mounted), you can run it once and be done with it. It only goes 100 folders deep, but you can modify that by changing the {2..100} to another range, like {2..500} for 500 folders deep. Running more layers deep increases runtime, so I assumed you wouldn’t have more than 100 layers of folders, but if you do you can adjust it.

Subdirectory version

#!/bin/bash

find . -maxdepth 1 -type d -name "_*" | while read FOLDER; do
    newfolder="$(echo ${FOLDER} | sed -e 's/^\.\/___/a/' | sed -e 's/^\.\/__/b/' | sed -e 's/^\.\/_/c/')" ;
    mv "${FOLDER}" "${newfolder}" ;
done

for i in {2..100};
do
    find . -mindepth $i -maxdepth $i -type d -name "_*" | while read FOLDER; do
        newfolder="$(echo ${FOLDER} | sed -e 's/\/___/\/a/' | sed -e 's/\/__/\/b/' | sed -e 's/\/_/\/c/')" ;
        mv "${FOLDER}" "${newfolder}" ;
    done
done

I assume that you at most have 3 underscores preceding a folder name. If that is not the case, you can modify the script as following.

If you have more, copy one | sed 's/.../' part for each find section up to the next | symbol (there is only 1 find section for the no subdirectory version and 2 find sections for the subdirectory version) and paste it before or after the others. If you are using the subdirectory version, make sure you copy the corresponding version of the sed command because they differ (the first one containes “^.” that the second one doesn’t)! On your new pasted copy, add an underscore to the part of the text you pasted that has underscores. Then for each of the other sed blocks, change the letter they are replaced with to match.

Here is an example with 4 max underscores on the subdirectory script:

#!/bin/bash

find . -maxdepth 1 -type d -name "_*" | while read FOLDER; do
    newfolder="$(echo ${FOLDER} | sed -e 's/^\.\/____/a/' | sed -e 's/^\.\/___/b/' | sed -e 's/^\.\/__/c/' | sed -e 's/^\.\/_/d/')" ;
    mv "${FOLDER}" "${newfolder}" ;
done

for i in {2..100};
do
    find . -mindepth $i -maxdepth $i -type d -name "_*" | while read FOLDER; do
        newfolder="$(echo ${FOLDER} | sed -e 's/\/____/\/a/' | sed -e 's/\/___/\/b/' | sed -e 's/\/__/\/c/' | sed -e 's/\/_/\/d/')" ;
        mv "${FOLDER}" "${newfolder}" ;
    done
done

If you have fewer than 3 max underscores, you just delete the relevant sed parts and update the letters.

You can also let me know how you want if modified and I can do it for you if you’d like.

Using the subdirectory version

If you want to use the one that works on subdirectories, create a text file renamesubdirectories.sh in the folder you want it to start from, and paste in the subdirectory script into that file with whatever text editor you prefer. You can then modify the script if necessary.

I’m going to try to give GUI instructions, but I haven’t used Nemo in a long time, so I’ve also provided terminal instructions in case those don’t work.

Nemo

Navigate to the folder you want to start from in Nemo. Copy or move the renamesubdirectories.sh file into this folder (or create the file here if you haven’t done so already, and paste in the subdirectory script, modifying if necessary). Right click on the file and open its properties/permissions (maybe details? Can’t remember exactly what the option is called). Find the setting to adjust permissions of the file, and allow it to be executed as a program/mark it executable, whatever adding the executable permission is called in Nemo. Now you can exit the permissions/properties/details window, and right click the file and run. After a few seconds, refresh (F5 usually). You should now be done and can delete the file.

Terminal

Navigate to the folder you want to start from, and right click > Open in terminal (I believe Nemo has that option, but it’s been awhile; let me know if not, and I can explain now to navigate there from terminal). Now make the file executable with chmod +x renameunderscores.sh. Run it with ./renameunderscores.sh. Once the next line prints (with your username, hostname, and directory), the command is done and you can exit the terminal and delete the file.

Using the non-subdirectory version

This will require you to either move the script every time you want to run it, or installing it locally and using the terminal (which is easier). I will explain the terminal version only for this, as moving the script every time you want to use it is very tedious.

Again, create the renamesubdirectories.sh file using the text editor of your choice, and modify as necessary. Then create a folder called bin in your home folder (this should automatically be in your path) and copy or move the renamesubdirectories.sh file into that folder. Then (in the bin folder) right click and open in terminal in Nemo, or just open a terminal from applications and navigate to the folder with cd ~/bin. Now make the file executable with chmod +x renameunderscores.sh.

You should now be able to navigate to any folder you want, then right click open in terminal, and run the command renameunderscores.sh. Once you are finished, you can delete the bin folder.

This is not very common knowledge, but it is no longer recommended to press S or U before B for SysRq. The official documentation of sysrq has stopped recommending this practice, as it may be harmful to modern filesystems. Writing to a storage device while the kernel is in a bad state has the potential to cause corruption, and modern journaling filesystems like EXT4 and BTRFS are designed to survive crashes like this with minimal (or no) corruption. Instead, you’ll likely want to use Alt+SysRq+REIB (and make sure you are waiting multiple seconds between each keypress, as they do not complete instantly!).

You may instead try to kill the most memory intensive non-vital process with Alt+SysRq+RF, which may stop you from crashing to begin with (this works especially well for memory leaks). SysRq+F will invoke the oom (out of memory) killer, which will kill the most memory intensive non-vital process without causing a kernel panic.

If you need to restart, the most ideal situation is to enter a TTY and cleanly reboot, in which case you can do Alt+SysRq+R to grab control from the display manager, then Ctl+Alt+F3 or Ctl+Alt+F4 (I believe most distros have the first login session run on the TTY accessible from Ctl+Alt+F2) to switch to another TTY. You can then log in and do sudo systemctl reboot if your computer is still responsive. You may need to kill some processes before your system becomes responsive enough to log in on a TTY, which is where Alt+SysRq+F is useful, but in extreme situations it may require Alt+SysRq+EIB.

So a basic order of steps to try may look like:

1. Try Alt+SysRq+RF and wait a few seconds to see if your system starts responding. If not, you can either try it another time or two, or move on to 2.
2. See if you can switch to a TTY with Ctl+Alt+F3. If so, try to log in and sudo systemctl reboot. Else move onto 3.
3. If you are in a TTY, switch back to the main login with Ctl+Alt+F2. Then do Alt+SysRq+REIB.

In the spirit of other users giving mnemonic devices, you could remember REIB with Reboot Even If Broken, or the oom killer RF with Resolve Freeze (someone else can probably think of something better for RF; I’m not great at making mnemonic devices).

TL;DR: There are SysRq combinations that are less prone to damage/corruption than Alt+SysRq+REISUB, so use the above flowchart, or just remove the S and U for Alt+SysRq+REIB (if you don’t want to troubleshoot first) for less chance of filesystem corruption from a bad kernel. You can often recover the system without having to hard reset (Alt+SysRq+B). And ALWAYS wait between SysRq keys, as they do not finish instantly.

But browsers should be installed as an RPM, because Flatpak uses the same seccomp filter for all apps. That isnt even really secure, but prevents browsers from spawning user namespace sandboxes. Which means they have very little process isolation.

User namespaces are not the only method of sandboxing in Linux. I use Mullvad browser, which is a fork of Firefox maintained in tandem with the Tor browser (without Tor integration), so I’ll mainly discuss Firefox. Here are some relevant comments on Firefox’s internal sandbox in flatpaks:

Firefox’s internal sandbox is designed to function properly without user namespaces or chroot

Firefox uses nested seccomp filters to achieve process isolation

The TL;DR is that Firefox uses seccomp-bpf on each process (with per-process nested seccomp filters) to intercept all syscalls for sandboxing, which does not require the use of user namespaces. User namespaces are used where possible, simply to add an additional layer of padding as a method of defense in depth. Since the syscalls are already intercepted and handled with seccomp-bpf, it could easily be argued that this is redundant and unnecessary given the way the Firefox sandbox works, based on the comments of the Firefox developer I linked to.

Chromium browsers had very bad issues with sandboxing, as they assumed that user namespaces would always be available (which breaks on any distro with them disabled in the kernel, as was the case with Debian and Arch just a few years ago, or any install that uses the linux-hardened kernel), and Chromium does not use seccomp-bpf for their process isolation like Firefox (or at least it didn’t when the bugzilla I linked to was made). I believe those issues have been fixed however, and Chromium-based browsers (at least the ones that implement the patch or something similar) should also have proper process isolation in flatpaks now. I don’t follow that very closely since I don’t use Chromium-based browsers, though. Here’s the flatpak Chromium patch that uses flatpak-spawn to fix process isolation in Chromium-based browsers for reference. It was mentioned in one of the Firefox bugzilla pages I linked to earlier. Since it isn’t an upstream fix, I wouldn’t trust that all Chromium-based browsers use it, but that’s an issue to bring up with Google (assuming it hasn’t been fixed upstream in the past couple years). Firefox specifically designed their sandbox to work in these situations where Chromium may fail.

Mullvad Browser isn’t available as an RPM (or even DEB), and while they have a tar.xz download that I imagine just installs the browser in the folder it’s extracted to (not source tarball; it’s all pre-compiled), I have no idea if that receives automatic updates, and I’ve never used a Linux app packaged like that, so I choose to use the flatpak instead.

SteamOS currently runs 6.1, which is an LTS kernel, it just isn’t the latest LTS kernel (that’s 6.6 released at the end of 2023). Steam also makes modifications to the kernel they use in SteamOS, so they have their own versions custom built for Steam Decks. I should revise my previous statement slightly. Debian Bookworm is on 6.1 as well, but SteamOS 3.6 (in beta) uses 6.5 (which is non-LTS). Debian skips every other LTS kernel because they release every 2 years, but SteamOS (eventually) upgrades each LTS kernel or some non-LTS between? They did the same thing with 5.13 a couple years ago (5.10 and 5.15 are LTS). I don’t really follow their releases since I don’t own a Steam Deck, so I don’t really know the rationale there. Funnily enough, looking through posts about it online, it seems that SteamOS is sometimes ahead of Debian on the minor kernel version and sometimes behind (when they’re on an LTS kernel). Currently, they are behind Debian on minor release (6.1.52 vs 6.1.76). Very strange, no idea what’s going on there.

But I specifically mean the packaging delays. There are sometimes sync issues with drivers, like this recent one with no free stuff that is used alongside the normal stuff.

Hm, interesting. I don’t recall experiencing anything like that personally since I hardly use anything from RPMFusion, but that does seem frustrating. Looks like it was fixed very quickly, at least.

And with Cisco-openh264 they cant to anything, Cisco ships the packages which is legally binding, and there are issues sometimes.

Ah yeah, I’ve heard about that. I can’t remember the last time I installed Cisco’s openh264 though since I started using VLC, which can handle video and audio formats without installing extra codecs. I think MPV can do the same? I’m not sure what comes with my browser, but it is packaged as a flatpak and seems to run media just fine. Maybe there is some other use for openh264 that I’m not aware of that just doesn’t come up in my normal use, but I don’t think I’ve installed any media codecs in Fedora for a couple years now. Granted, I don’t play videos often (but I do play MP4s when I do), and all my music is in FLAC format, so I’m probably an edge case. I also don’t game, but I remember seeing something recently in this sub where someone may have had codec issues while playing a game.

But Fedora is doing a great job, and the fact that rpmfusion exists alone is pretty hillarious. These are obviously Fedora people maintaining the stuff in secret, in a country where patent laws are not enforced (but are also in place afaik).

Well, Fedora is a community project, so it’s very difficult for anything individual maintainers do to come back to Fedora so long as the name isn’t put on it directly. If I were to speculate, most of the RPMFusion maintainers are Fedora community contributors (and I imagine they likely wouldn’t work at Red Hat, given Red Hat’s apprehension towards copyrighted material). I don’t think it’s really any different legally speaking from a Fedora contributor working on a personal project on the side. The fact that you can manually add the repo to Fedora doesn’t connect the two in a legally binding sense. So as long as it isn’t being funded by Fedora, and their branding is absent, then it shouldn’t really matter. I don’t know about the actual legal aspects of the packages they are distributing, or what country/countries RPMFusion repos are hosted in, but so long as nobody is profiting/losing substantial profit, it likely isn’t even worth pursuing any legal recourse to begin with.

You are at the bleeding edge, but I often find bugs that are simply there and need to be fixed. Once KDE Plasma 6 is on some LTS release like CentOS Stream, I may think about switching.

Yeah, that’s fair. There are definitely bugs that pop up every once and awhile, but for the most part they’re minor (at least the ones I notice). This kernel bug is among the more major bugs I’ve seen with Fedora in the past few years, but I only know about it from this post; I haven’t experienced it myself. I imagine there have been similar things (or worse) like this that have gone over my head as I didn’t experience them myself. Perhaps my experience has also been more stable because I’ve been using GNOME up until Fedora 40. I do find my experience with Fedora to be much more stable than Arch, but that is to be expected given their release models. I can only recall having experienced 1 or 2 bugs in the past year on Fedora, which is less than I experienced when I used Ubuntu many, many years ago, and the bugs were fixed much faster than they were on Ubuntu, where it would often take months for a patched version of the package to enter the Ubuntu repos. That’s all anecdotal, however.

The reason I usually recommend Fedora to people (and uBlue images by extension) is that it sits on some middle ground between the rolling release bleeding edge distros like Arch, and the stable, LTS, frozen for 2 years distros like Debian. I have grievances with both of those models that are addressed with Fedora, and that’s what makes it a good distro for me. My experience with bugs hasn’t really been any more common than when I was using LTS distros, but that may be a fluke. I will likely be moving one of my servers to Debian in the future though, because it makes sense for its purpose. Different release models benefit different uses (and people), of course.

Actually, this particular issue is a bug in the Linux kernel that has been patched in version 6.9. The display manager isn’t going to change anything other than (maybe) the issues their wife had on Bazzite. In fact, OP stated in their post that they are running an AMD GPU (5700XT). Fedora 40 (and Bazzite by extension) ships without X11 installed now. You can always install the X11 package as an overlay and switch to it if you want with Fedora Atomic or Bazzite. It’s still in the repos, it just isn’t the default anymore. So realistically, the solution here is to wait for the 6.9 release to be added to the Fedora 40 repos, or for a 6.8 version which has the fix backported (which will be much sooner, probably a few days after the backport is merged, though I don’t know if that has already happened yet or when it will if not). The reason Mint works is because it uses a much older kernel version, so this bug is not present. The bug was first introduced in 6.6.30.

Yes, that may be the case, but that comes with its own downsides as well. The most recent version of SteamOS runs the 6.1.52 kernel from September (thus it should be unaffected by this bug, since it was introduced in 6.6.30). I don’t follow kernel changelogs very closely (so I don’t know all the new features and improvements that are being missed from new versions), but there are lots of optimizations and new features constantly being added to the kernel. Of course, the tradeoff is that you don’t get new bugs, but you also have to backport bug fixes or else you’ll have the bugs present in your current version for a very long time (often the kernel devs do this, but depending on what version a given distro uses, the distro maintainers may have to do it themselves). It’s not as big of a freeze as Debian based systems (EDIT: Some of the time; right now they are technically behind Debian on the kernel minor release, but in SteamOS 3.6 (which is in beta), they will be updating to 6.5), of course, but it’s a choice that has tradeoffs. Different people will subscribe to different opinions on kernel updates, given that no one way is clearly superior for user experience and features alike.

As for proprietary packages that are held from Fedora for copyright issues (media codecs and Nvidia drivers, for instance), there are always uBlue images like Bazzite, Bluefin, and Aurora that fix that. One of the very few stipulations to the Red Hat sponsorship for Fedora is that they do everything possible to avoid legal trouble, hence why those packages aren’t included in the base repos or installed by default. It’s a small caveat that disappears once you install the correct packages.

I think SteamOS is by far the most optimized OS for the Steam Deck, but I don’t think it’s very useful to use it on any other hardware (there are better options). Kernel updates will always be a point of conflict for at least some people regardless of what model you use, but I personally appreciate the quick turnaround for major kernel versions in Fedora. It’s actually improved my experience on my laptop significantly, as there have been recent changes that apply to my specific hardware (in some of the 6.6 releases, for instance). Of course, anyone can be free to prefer a slower rollout, and that is equally valid. The bug fixes for the issue OP is having should be backported to 6.8 anyway, so it shouldn’t necessitate waiting for 6.9 to hit Fedora in a few weeks.

Fedora does test everything before they ship it. Each major kernel release can go through as much as a month of testing for stability and regression. SteamOS is based on Arch, where they don’t test the kernel for regression. Despite testing though, this is an incredibly obscure issue, and obviously the Fedora team can’t catch every kernel bug. It only happens on some hardware, and only in the event that the VRAM visible to the CPU is filled, and less used portions of the CPU-visible VRAM are moved to other parts of VRAM that only the GPU can see. This is why resizable bar fixes the issue for many, as it makes all VRAM visible to the CPU, so there is no move that happens (moving the VRAM data has an off by one error). This issue goes all the way back to 6.6.30, and was only discovered 3 weeks ago, and took 2 weeks to find the root cause of and patch in the stable version of kernel 6.9. It was only found because the 6.9 release candidates added checks for hardware capabilities, and the off by one error that is the root cause of this issue threw an error with the hardware capability checks. I’m not a kernel developer, so I don’t know all the details, but it is discussed in the issue I linked if you want more explanation.

Actually, this particular issue is a bug in the Linux kernel that has been patched in version 6.9. The display manager isn’t going to change anything other than (maybe) the issues their wife had on Bazzite. In fact, OP stated in their post that they are running an AMD GPU (5700XT). You can always install the X11 package as an overlay and switch to it if you want with Fedora Atomic or Bazzite. It’s still in the repos, it just isn’t the default anymore. There’s no need for an image with X11 in it by default, especially with explicit sync support coming soon that will fix many of the remaining issues with Nvidia on Wayland.

I replied about getting the updated kernel on Bazzite on another one of your comments, but I want to clarify that this is not only a bug for those that have resizable bar and 4g decoding as BIOS options, and it does not always happen on game start. I just want to reinforce that this is very likely the exact issue you are experiencing, and it is patched in kernel version 6.9. The only reason you don’t see the popup from the linked issue is because that is a check that was added in 6.9rc-5 to validate hardware capabilities; the root issue underneath has been present since 6.6.30, but only results in a crash with no error dialog. This particular kernel bug happens when the CPU runs out of VRAM space that is accessible to it, and tries to move data to other parts of VRAM (with the help of the GPU) to make space in the section visible to the CPU. Since resizable bar makes all VRAM visible to the CPU, that’s why it fixes the issue for some, but that is not the root cause of the problem. There is an off by one error discussed in the kernel bug thread that was linked that incorrectly handles the VRAM swapping and only became an issue after a check was written to validate the hardware capabilities (which fails due to the off by one error). This can happen after some time playing the game, after the CPU-accessible part of VRAM is filled up, however long that takes.

This will be fixed in a few weeks when the 6.9 kernel is pushed to the Fedora repos, or you could compile and install the 6.9 kernel using my instructions on your other comment. Or you could continue to use Mint until the kernel is updated, whatever works for you. Other than this one obscure kernel bug, Bazzite will generally be the much better option for gaming as far as performance and user experience goes. Mint follows the Debian/Ubuntu update cycle, so its kernels are old and without many enhancements to gaming that exist in the newer versions of the kernel present in Bazzite and Fedora. Of course, you can choose whatever distro you’d like, I just wanted to provide a method for you to switch back to Bazzite if you prefer it (and explain what the issue is and how to fix it).

Yes, this is patched in 6.9. Since it’s a new major release, it’ll take a few weeks before we see it in Fedora while they check for major regressions and stability. Stable updates (like 6.8.8 to 6.8.9) are much quicker, usually taking only a few days, but major releases add much more to the kernel and need to be properly tested for regression. If you wanted to use Bazzite, you’d have to compile the 6.9 kernel yourself and overlay it, though I’m not sure the steps you’d need to take exactly given that I’ve never tried compiling the kernel for an atomic distro before. Perhaps you can find something online about it, but I didn’t find an easy guide when I searched it (just non-atomic kernel compilation). I did find documentation on how to change the kernel in an rpm-ostree based system, but you’ll still have to compile it yourself and then override the rpm you compile with that method. Instructions on compiling a kernel for Fedora can be taken from here for reference.

I’m going to hack together some stuff from both sources with what I think will work in Bazzite using rpm-ostree (and a toolbox so you don’t have to overlay a bunch of packages as build dependencies). This is untested, as I really don’t want to have to compile a kernel myself; my computer isn’t nearly fast enough for that to be reasonable right now. If anyone tries this, please let me know if this works or not. Luckily, based on the custom kernel documentation, it seems this process is quite easy with Fedora’s kernel dist-git. No manual configuration should be required, just a few commands (Secure Boot complicates things dramatically, but the Fedora documentation already has the instructions for getting this to work with Secure Boot, so that should hopefully just work).

None of the commands I provide are irreversible, and can be reverted easily. Since we are working with an atomic distro, you can always rollback to a previous version if you encounter issues. Reverting to the default kernel is as simple as removing the override we create for the compiled one.

WARNING: This will use Fedora 41’s kernel configuration. It may differ from both Fedora 40 and Bazzite’s kernel configuration. Understand that there is a small chance this will cause problems, in which case you can rollback to the previous version or remove the override at any time to uninstall and revert back to the base kernel.

Open up a terminal, and enter the default toolbox (if you do not have a default toolbox yet, you can create one with toolbox create)

toolbox enter

From the Fedora custom kernel documentation

Install dependencies inside toolbox

sudo dnf install fedpkg
fedpkg clone -a kernel
cd kernel
sudo dnf builddep kernel.spec

Checkout from the Fedora kernel dist-git

git clone https://src.fedoraproject.org/rpms/kernel.git

Switch to Fedora 41 branch (since it has 6.9 already)

git switch f41

Do you use Secure Boot? Because if you do, then it gets WAY more complicated and I don’t know for a fact that this will work properly. Only do the stuff in the Secure Boot section if you use Secure Boot!

---------------SECURE BOOT CONFIG---------------

NOTE: Update values enclosed in <> to appropriate values (for example, changing <your name> to mranachi or <MOK certificate nickname> to MOK-temp-6-9-kernel)

Add your user to /etc/pesign/users if it does not already exist.

nano /etc/pesign/users

Run authorize user script

sudo /usr/libexec/pesign/pesign-authorize

Create a new Machine Owner Key

openssl req -new -x509 -newkey rsa:2048 -keyout "key.pem" \
        -outform DER -out "cert.der" -nodes -days 36500 \
        -subj "/CN=<your name>/"

Import MOK into your UEFI key database

mokutil --import "cert.der"

Create a PKCS #12 key file

openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der

Import the certificate and key into the nss database

certutil -A -i cert.der -n "<MOK certificate nickname>" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
pk12util -i key.p12 -d /etc/pki/pesign

Add line %define pe_signing_cert <MOK certificate nickname> to the kernel.spec file (I am assuming it is in the current directory based on the wording of the Fedora documentation, though I have not seen any of these files. It may be located elsewhere, but I have no idea where if that is the case)

nano kernel.spec

---------------SECURE BOOT CONFIG---------------

Build RPMs using the default Fedora 41 configs (this could take a very long time on slow hardware, but assuming you have a good CPU, it could actually take as little as 4 minutes)

fedpkg local

Exit the toolbox so we can install the RPM

exit

From the rpm-ostree kernel change documentation

Install the new kernel. I don’t know what the name of the RPM will actually be, so you may want to ls x86_64 and modify this command to match the appropriate RPM(s). Also, I can’t remember if exiting the toolbox keeps you in the same folder, so you may need to navigate back to the correct folder with cd kernel after exiting.

rpm-ostree override replace ./x86_64/kernel-*6.9*.rpm

Clean up

cd ../
rm -r kernel/

You may also optionally want to remove the build dependencies inside the toolbox if you want to save space.

Reboot, and in theory, you should be done (if you did the Secure Boot steps, you’ll have to accept the key when you reboot). I’d like to remind you that you can rollback any changes if you encounter any issues, as that is one of the many benefits of atomic distros.

Uninstalling compiled kernel

To revert the override (once 6.9 releases to Fedora 40 repos), simply do the following (this effectively uninstalls the compiled kernel and reverts back to whatever is in the base image):

rpm-ostree override remove kernel-*6.9*.rpm

Bazzite is definitely a great option if you have an Nvidia card or you are looking for gaming performance. It includes some gaming oriented features and optimizations like the System76 scheduler that aren’t in the regular Fedora Atomic builds that have the potential to increase performance, and make things easier (such as having a build with Nvidia drivers in the root image). I don’t really game at the moment, so I don’t have personal experience with Bazzite, but I’ve been on Fedora Atomic KDE for a while now and it has been a great experience. I’ve heard lots of great things about Bazzite, so I would expect it to be a similar experience (maybe a bit easier). I feel comfortable recommending both, but the more appropriate choice will depend on what you use your computer for and your own preferences, of course.

While I haven’t personally rebased to a different image before, it should be pretty seamless, except for some potential config issues if you are switching to an image with a different DE (i.e. switching from GNOME to KDE). I’ve seen people in this community mention successfully rebasing to another DE, but Bazzite’s documentation recommends against it. I imagine that there may be config issues in /etc or in your home folder from switching DEs, just as may be expected when switching to a different DE on a non-atomic system. Your milage may vary there, essentially; Fedora and uBlue just don’t officially test rebasing between different DEs. I usually tend to be cautious in my recommendations, so I generally recommend users to try out different DEs on a VM before deciding on one, and to do a full reinstall when switching DEs. There’s a chance that is overkill, but it is certainly safe. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example. It seems that the issues can be fixed, but since the rebase between DEs is not officially tested, it is prone to small issues like these (though it appears at least some of the ones in that post have been fixed upstream now). The issues in that post were all incredibly minor, so you could likely fix your system in place if you were to try this (maybe you won’t even have any issues; half of the post was about an issue caused by the fish shell, which is not the default), though you’d have to know where to look to find any issues (I’d start by checking overlaid packages and seeing if there are any from the old DE). You can always rollback safely, as each previous version the OS saves has it’s own unique /etc folder (even though it isn’t part of the root image).

Switching between Fedora Atomic and Bazzite is more supported (when you keep the same DE), but different images can add and remove packages from the root image, so you may find that you’ll need to overlay packages/remove overlays when switching between them (such as Nvidia drivers). I don’t imagine that posing an issue as an end user in most cases (outside of the Nvidia drivers), just thought it was worth mentioning, as it is an edge case that could pop up. That’s one of the reasons that adding overlays isn’t the first recommendation for installing packages, as they have the potential to make rebasing a bit more complicated for a handful of packages that may be different between different images. I would imagine that an update (or even the rebase itself) would fix any dependency issues (hence why I don’t see it being an issue for an end user in most cases), but I don’t know that for a fact. None of my information on rebasing is based on experience, except for rebasing to a new major version (i.e. Fedora 39 to Fedora 40), so you should look into that more yourself if you want more concrete details. Also, I mistakenly mentioned rebasing to a previous version of your image from before an update. That is actually called a rollback, and uses the rpm-ostree rollback command, more info here (I’ve edited my previous comment to reflect that). Bazzite has some good documentation on rebasing here, and I don’t see any mention of package conflicts between Bazzite and Fedora Atomic, though you will likely want to remove an Nvidia driver overlay if switching from Fedora Atomic to Bazzite. You very likely won’t need to make any other changes. There are people in this community with far more rebasing knowledge than I can provide/find from searching, so you can always make a post asking about it if necessary, and someone should be able to help.

It’s also helpful to note that documentation for Fedora Atomic (sometimes you get better search results by using “Silverblue”, as that was the original project name), Bazzite, and Bluefin are often interchangeable, as they are all based on Fedora Atomic. You may find some things more easily documented in Bazzite/Bluefin than on Fedora Atomic or vice versa, but much of that documentation applies exactly the same to any version. For any additional information about rpm-ostree, I would unironically suggest reading the manual page through man rpm-ostree or online at a site like this if you aren’t comfortable with the terminal interface for man pages (quick tip: you can search for a term in man by typing / followed by the search term, and you can use n and N to go to the next/previous occurance).

I’m just here to help people out when I can, so if my comments are able to help anyone, I see it as time well spent. Sometimes it even helps me learn new things myself, and cements concepts I was already familiar with, so it’s mutually beneficial!