There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Bazzite ? maybe not for V-rising.

I’ve been seeing a lot of bazzite recommendations recently, and it sure sounds great. An atomic fedora, gaming optimisations out of the box. It just works.

We’ll that’s not been my experience for V-rising, and I wanted to share it incase others anyone else encounters the issues I did.

First and foremost I am sure there major issue is the game, more than any given distro. I’ve been happily running arch on my home PC for 7 years. Its been great, no issues, I’ve loved it. As my free time decreased, that computer had become just for gaming. The maintenance debt was building up, I knew the dream run with arch must end. That end was V rising, crashed frequently, all kinds of stage behaviour. I assumed a vulkan issue, but couldn’t easily find a fix, and didn’t want to waste any more time on it.

I went with Bazzite, but to no avail. The crashing problem got worse. Only now i had to deal with the sluggish flatpack versions of things. Its not that bad, but us a was a very noticeable change.

If it had just been me, I think this is whereui would have given up. But I was playing with my wife and mate online, both of whom also use Linux and weren’t having the crashing issue. On my wifes computer i had recently installed bazzite. It did have issues, mostly flickering which i chalked up to a too early switch to Wayland on a gtx1080. My mate was on mint, with a 3060 and v rising was working perfectly.

I switched to mint (I am running and a 5700xt), and my problems were fixed just like that.

Next was to solve the wife’s woes, so I switched her to mint too. Which resulted in v rising not being able to load, freezing up the computer every attempted requiring a X restart. Didn’t matter which version of the nvidia drivers i used. The flickering was gone though, so that was something. Pop-os was the solution, took a bit of understanding popshops preferred order of events to get nvidia drivers installed, but now all is fine.

So the lesson I think i might have learned, old hardware and new (vulkan) games require unidentified settings to work and easiest solution is just distro hop till success. Big shout out to steams transfer over network functionality (i also needed to install bg3 each new distro, it ran fine on every combination but bazzite was noticably more flaky).

It doesn’t matter, but does any one have and ideas as to why v rising caused such headaches? 7 years a Linux gaming, and nothing has required more than a few hours of tinkering at most to get to work until this.

Tldr. Needed a safe space to debreif, everything worked out in the end.

narc0tic_bird ,

For what it’s worth V Rising works fine on my desktop PC and my Steam Deck. Audio can stutter with a lot of SFX being played at the same time, but I have that happen occasionally in a few games on both my PC and the Deck.

PC is a Ryzen 7950X3D + Radeon 7800 XT running openSUSE Tumbleweed with kernel 6.9.1 (worked under 6.8.* as well), KDE 6 under Wayland, Steam Flatpak. Like others mentioned I have above 4G encoding and reBAR enabled, as they were enabled by default on my ASUS B650E-E.

Works on the Steam Deck under Bazzite and SteamOS.

boredsquirrel ,

This is not about mint but random proprietary NVIDIA drivers not working with Wayland.

I dont know if ublue offers any X11 images now that F40 removed the X11 packages by default.

You dont need to distrohop, you need a Bazzite image with X11 support. This is mostly unsupported legacy cruft and mostly NVIDIAs fault.

Para_lyzed ,

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.

olafurp ,

On Bazzite you could also swap to the gnome version for a bit without worrying. That one is still X11

boredsquirrel ,

True its still in the repo, I thought it was only on COPR.

Dont know GPU names but well, that is the issue when using Fedora and not SteamOS, where they test everything before shipping it.

Para_lyzed ,

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.

boredsquirrel ,

Nice, thanks for the info!

Yes but I mean Steam may test many games with this specific setup. Fedora is a way better base in general, if you leave out the issues with external repos (mainly openh264, rpmfusion is maintained by fedora people, 100%)

Para_lyzed , (edited )

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.

boredsquirrel ,

Very true. I am also very critical of any form of “stable packages”. Firefox ESR the LTS kernel are the only exception but if SteamOS doesnt use the LTS kernel then wtf are they doing?

I honestly dont care about gaming :D I waste way too much time away from touching grass anyways.

But I hope they backport all security fixes anyways, as the SteamDeck is now one of the most predictable Linux botnet-targets out there.

there are always uBlue images like Bazzite, Bluefin, and Aurora that fix that.

Yes I know and use uBlue since basically it came out :D awesome project

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.

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

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).

It’s actually improved my experience on my laptop significantly

I guess so too? I dont know, Fedora Kinoite (whatever small derivative, currently ublue kinoite-main, soon aurora) works just really well.

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.

But until then, Fedora is just really good.

Para_lyzed ,

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.

boredsquirrel ,

I use celluloid flatpak which has native wayland and pipewire support. Its an MPV GUI.

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.

Para_lyzed ,

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.

boredsquirrel ,

Late reply, had this in my inbox for a while.

Interesting bugzilla thread indeed.

seccomp vs userns

I dont know about the security difference between nested seccomp filters and user namespaces. I dont know how good the achieved process isolation is.

But I can imagine that the Firefox approach is better.

chromium

Also note that Chromium has a setuid sandbox mode which is kept as fallback. Found that through secureblue.

I know that bubblejail is currently broken for me, I will uninstall it, remove the configs and reinstall it again.

I think running FF with userns enabled AND isolated with bubblejail is best, and it is possible.

flatpak and seccomp

Flatpak has a real issue with their loose and kinda random badness-enumerating seccomp filter. See this issue

The problem is, app devs dont know shit about seccomp, some other project (was it GNOME?) just uses the Flatpak filter because they also dont know enough about it.

It would be best to have a modular approach, with “security building blocks”.

Browsers have the “base” set of rules, which is the most unrestricted there is, allowing user namespaces.

All apps by default get the “standard” set which is base, without userns.

And there can be a more secure one for strong and verystrong isolation.

browser updates

Firefox has a builtin updater, Distros just remove that. So the Mullvad Tarball and also an official Firefox or Thunderbird tarball will autoupdate.

But as the app lies in an insecure location, its source could be modified. So it is always best to have apps somewhere only root can change.

Same for flatpaks actually, –user flatpaks are installed to the user homedir without any permissions and could be tampered with by any process.

d3Xt3r ,

This has nothing to do with Arch or Bazzite, it’s actually a bug in recent kernels. Switching to Mint only fixed it for you because Mint uses an old kernel.

The fix/workaround is to enable “above 4G decoding” and “resizable BAR” in your BIOS. If your BIOS does not have these options, you can either downgrade to an earlier kernel (or OS image if you’re on Bazzite), or switch to a patched kernel like the Cachy kernel.

JustEnoughDucks ,
@JustEnoughDucks@feddit.nl avatar

Yep, it is also worth to note that 6.9 rc6 (iirc) fixed this issue, and mainline 6.9 should have this issue fixed.

Literally fixed by adding 1 = sign 😁

Fredol , (edited )

distrohopping till success it not a solution…

"Thanks to @Thorondir, I was able to resolve my crashing issues that began with 1.0: “Since 1.0 I couldn’t start the game anymore. Turns out it’s a kernel bug! See gitlab.freedesktop.org/drm/amd/-/issues/3343

Enable ‘Decoding Above 4G’ and ‘resize BAR’ in BIOS.”

mranachi OP ,

I’m not going back arch/bazzite to try this. For two reasons, 1. I can’t enable those things, my hardware doesn’t support reBAR. And 2. My issue sounds potentially different. I could load and run the game, but it would crash regularly. Realistically, if this is the issue my only solution is to roll back to an old kernel (not supported in arch), and I’m not sure if that fly’s in bazzite either. Distro hoping to Mint is then a great solution, even if I didn’t take a rational path there.

Fredol ,

you’d be better using debian than popos

Para_lyzed , (edited )

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).

TreeGhost ,

I don’t have V-Rising, and I’m sure a lot of this stuff is hardware dependent, but according to a couple of reports on ProtonDB, there might be a kernel bug causing issues with it.

www.protondb.com/app/1604030

I just installed bazzite on my LCD Steam Deck this week and it has been pretty solid so far, but obviously the hardware support for it is top notch thanks to Valve. I didn’t have really any issues with regular SteamOS either and just wanted to try something a bit more customizable.

And really Linux gaming on the Steam Deck feels like cheating, especially compared to trying to run games via wine before the proton days.

mranachi OP ,

Oh yeh good catch.

I can’t do resizable bar, so it would have been a kernel regression to fix (if that was the issue). I think patched in next release. Although I never got any error messaging in any logs that i could see :(

The nice thing about the deck, at least from an outsiders perspective, is that everyone’s got the more or less same hardware. If you have an issue most likely someone else has the same issue, and already has a fix that’ll work for you.

Para_lyzed , (edited )

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)


<span style="color:#323232;">toolbox enter
</span>

From the Fedora custom kernel documentation

Install dependencies inside toolbox


<span style="color:#323232;">sudo dnf install fedpkg
</span><span style="color:#323232;">fedpkg clone -a kernel
</span><span style="color:#323232;">cd kernel
</span><span style="color:#323232;">sudo dnf builddep kernel.spec
</span>

Checkout from the Fedora kernel dist-git


<span style="color:#323232;">git clone https://src.fedoraproject.org/rpms/kernel.git
</span>

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


<span style="color:#323232;">git switch f41
</span>

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.


<span style="color:#323232;">nano /etc/pesign/users
</span>

Run authorize user script


<span style="color:#323232;">sudo /usr/libexec/pesign/pesign-authorize
</span>

Create a new Machine Owner Key


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

Import MOK into your UEFI key database


<span style="color:#323232;">mokutil --import "cert.der"
</span>

Create a PKCS key file


<span style="color:#323232;">openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der
</span>

Import the certificate and key into the nss database


<span style="color:#323232;">certutil -A -i cert.der -n "<MOK certificate nickname>" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
</span><span style="color:#323232;">pk12util -i key.p12 -d /etc/pki/pesign
</span>

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)


<span style="color:#323232;">nano kernel.spec
</span>

---------------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)


<span style="color:#323232;">fedpkg local
</span>

Exit the toolbox so we can install the RPM


<span style="color:#323232;">exit
</span>

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.


<span style="color:#323232;">rpm-ostree override replace ./x86_64/kernel-*6.9*.rpm
</span>

Clean up


<span style="color:#323232;">cd ../
</span><span style="color:#323232;">rm -r kernel/
</span>

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):


<span style="color:#323232;">rpm-ostree override remove kernel-*6.9*.rpm
</span>
Bookmeat , (edited )

I had problems with multiple monitors on Bazzite when trying it out today. PopOS was okay, but it’s still runs X11, and Suse tumbleweed would crash due to graphics issues. So I’m on Fedora 40 now and it’s working excellently (even V rising). F40 and Suse were the only ones to detect Windows on another disk and automatically make it available in the boot menu, which was nice.

mranachi OP ,

I run fedora 40 on my work laptop, and I am blow away at how capable Wayland+gnome is for plug and go multiple monitor support. You could never have done it with X, every meeting you’d want 15min to make sure you can share your screen.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • [email protected]
  • lifeLocal
  • goranko
  • All magazines
    •