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.
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.
https://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.
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.
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>tomranachior<MOK certificate nickname>toMOK-temp-6-9-kernel)Add your user to
/etc/pesign/usersif it does not already exist.nano /etc/pesign/usersRun authorize user script
sudo /usr/libexec/pesign/pesign-authorizeCreate 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.derImport 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/pesignAdd line
%define pe_signing_cert <MOK certificate nickname>to thekernel.specfile (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
