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.

  • Para_lyzed@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    5 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 to `mranachi` or 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=/"
    

    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 "" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
    pk12util -i key.p12 -d /etc/pki/pesign
    

    Add line %define pe_signing_cert 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