It looks like
6.5.3-cbe2.0.fc38 has issues for rpm-ostree?
While trying to perform
rpm-ostree upgrade today I got this:
Processing packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
error: Multiple kernels (vmlinuz) found in: usr/lib/modules: 6.5.3-cbe2.0.fc38.x86_64 6.5.3-cbert4.0.fc38.x86
rpm-ostree upgrade --preview:
kernel-cachyos-bore-eevdf 6.5.2-cbe1.0.fc38 -> 6.5.3-cbe2.0.fc38
kernel-cachyos-bore-eevdf-core 6.5.2-cbe1.0.fc38 -> 6.5.3-cbe2.0.fc38
kernel-cachyos-bore-eevdf-devel 6.5.2-cbe1.0.fc38 -> 6.5.3-cbe2.0.fc38
kernel-cachyos-bore-eevdf-devel-matched 6.5.2-cbe1.0.fc38 -> 6.5.3-cbe2.0.fc38
kernel-cachyos-bore-eevdf-headers 6.5.2-cbe1.0.fc38 -> 6.5.3-cbe2.0.fc38
kernel-cachyos-bore-eevdf-modules 6.5.2-cbe1.0.fc38 -> 6.5.3-cbe2.0.fc38
Hello, I’m also using Silverblue 38 on Nvidia but haven’t encountered this.
Can you provide any additional information regarding hardware?
This is the report for the error you’re encountering, you might want to try, if you have time, to run
rpm-ostree reset and then, without rebooting, trying to override the kernel on a clear base; This is just a way to eliminate other confounders such as the Nvidia driver. Good Luck!
I was reflecting on something, I’ve recently seen some benchmarks on BORE-EEVDF showing some nice 1.5-2.5% performance improvements in gaming workloads compiling the Kernel with LTO.
Is there any more detailed information as to why the LTO version is unmaintained in this repo and, if there’s any more substantial data to show performance improvements, could it be an idea for someone to rebuild it?
I would suggest the same.
You can also try “rpm-ostree override reset kernel-cachyos-bore-eevdf”
so you only reset the kernel back to default.
you can then try to layer the kernel again without reboot. if its still not working then try with a reboot in between them.
the problem we have is that we can’t build using Clang on COPR. only gcc can be used.
it was actually never compiled with clang because copr doesnt recognize the clang flag.
I understand, very interesting issue.
CachyOS itself has always been very tempting for me, the Phoronix benchmark, when you remove the Python and SQL regressions, actually shows a significant overall improvement.
Unfortunately I love the safe control and great defaults Silverblue provides; Thankfully this kernel exists!
I really hope Fedora takes more aggressive optimisations into consideration for the future, especially if they improve efficiency as well.
I totally agree.
i’m really in love with Silverblue/Kinoite for the safety it provides, especially when moving fedora version. Also the fact that I can build my custom image via a Dockerfile on Github is really awesome. So I can compile software in a container and copy the executables into my image.
Then i can choose at what interval i want my image to be rebuilt. everything automatically done on github’s servers.
I cant do this with a regular linux OS.
I agree about the optimizations. I think its a thing that is true for most linux distros but it seems that optimizations have got a bit more attention recently than it previously had.
Hello, devs. Thank you very much for doing a great job in maintaining this amazing kernel for Fedora. The kernel is very fast on my potato surface go 3. However, I would like to request you add linux-surface patches to this kernel as myself, as well as other surface device users, may not have all the functionalities working without them. I keep coming to this kernel only to find that my cameras don’t work and go back to the surface kernel again. It is the only thing stopping me from installing this kernel permanently. I hope you guys give this a thought. Thank you very much for your incredible work. Cheers!!!
Hello again, two weeks ago I reported an issue with installing any of the kernels on Fedora Silverblue 39; As the issue seems to be still present I was wondering if this has been tested (Silverblue 39) and, if that’s not the case, if I can provide some help in testing this to make sure it works.
Theoretically today is the scheduled release of the Beta for 39 so I think it could be a good idea to make sure this gets fixed if it’s not an issue on my end.
(It fails in doing this while moving from 38 → 39, I should probably also test the override on 39 itself while I am already in the updated deployment)
I’ll try to look into it.
Small update, I’ve tested Fedora 39 on a VM and this is still present. I did update from 38 to 39 on the VM but the actuall install happened on 39.
If you have any ideas about which logs could be useful in identifying this I’ll be happy to share them.
Can you hit me up on discord? My tag is trixieua
Thanks for the suggestion.
I will consider if I can add this to any of the upcoming releases of the LTS kernel
Most of the surface devices support x86_64v3 as well. I guess you can add the patches to main kernel
Howdy, I recently started trying out kernel-cachyos-bore-eevdf-rt, and I have noticed since the release of 6.5.4-cbert1.0 , that I cannot play certain games without the game crashing completely after an amount of time.
At the moment when I play Star Citizen ( a pretty demanding title) the game will hang at random intervals causing a crash of the game but not the system. Rolling back to the non-RT build of the kernel (still 6.5.4-cbe1.0) yielded the same results.
Running an even older build of the kernel (6.5.3-cbert1.0) saw the issue go away. I’m not quite sure what I can provide to help debug this.
Some people on Cachyos Discord serverd had same issue but they ended up running older kernel too, personaly I have 0 problems with 6.5.4 rt kernel so just use what works best for you for now.
Makes sense, using an older kernel isn’t the end of the world anyways.
the patches aren’t available for kernel 6.5. only 6.4 and 6.1 (which is the LTS version)