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.

  • mranachiOP
    6·
    6 months ago

    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@lemmy.world
      7·
      6 months ago

      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