If you’re on Bazzite you have to add a couple to the silverblue command. Once enabled, the copr, make sure to do:
sudo rpm-ostree override remove kernel kernel-devel-matched kernel-devel kernel-core kernel-modules kernel-modules-core kernel-modules-extra --install kernel-cachyos-rt
You add kernel-devel-matched and kernel-devel or you get an error instead.
@bieszczaders you can add these instructions if you want not really necessary if they check the comments
You can enable support for Secure Boot by self-signing the kernel with a key added as a MOK.
I wrote a guide for it here: CachyOS Kernel for Fedora with Secure Boot · GitHub
Hello there.
I can’t boot into graphical mode with kernel 6.15.1. With 6.14.8 works fine. Tried reinstalling NVIDIA driver 575.57.08 and the new kernel, ran akmod --rebuild and dracut regenerate, but still not able to fully boot. It gets stuck (after pressing ESC) in gdm.sevice, but plymouth only shows a frozen loading image (pressing ESC again)
[Edit]
Removing completely Negativo17’s drivers and using kernel-cachyos-nvidia-open it works, but with for games until now, the performance is not good and some crash when trying to open.
[Edit]
Definetely a bug, only after removing all driver related files; restarting and installing the driver again I was able to use my system again with kernel 6.15.1 with the proprietary driver.
Dealing with NVIDIA is tiresome 
6.15.1 works fine for me with an Intel GPU.
How could I do the same secureboot type signing on Bluefin/Aurora?
It seems it’s slightly more complicated to self-sign 3rd party kernels in Silverblue/Bluefin/Aurora. According to what I found this might be what you’d have to do:
To install a custom kernel on Fedora Silverblue, you typically need to build an RPM with your changes and then use the command sudo rpm-ostree override replace ./your-kernel.rpm to apply it.
So you need to download the rpm, extract it, sign the kernel, create a new rpm and then install it. And you’d want to make it automatic for all updates. Perhaps one way to do it would be using a cron job that checks for an updated kernel every X hours.
We can only hope that the CachyOS kernel will get (self-)signed like Bluefin, so that you just need to import the key using mokutil.
Hi mister, I’d like to report a recurring issue that I’ve encountered since kernel version 6.15.1, which still persists in 6.15.2 — though it occurs intermittently.
My system sometimes fails to shut down or reboot properly due to a failure in unmounting ZRAM devices. However, systemd still reports that the shutdown process completes successfully. I check log from Plymouth’s verbose mode (accessed by pressing the Esc key) and I get this.
Any idea how to fix it? I report this on GitHub Issue too, and I forwarding here
Does this happen with the official Fedora kernel too?
Hmmm this bug not appear before kernel 6.15.x on all versions
Hello! PLS help me! I cant install it, because i get it:
error: Could not depsolve transaction; 2 problems detected:
Problem 1: package kmod-zenergy-0.0.git.36.32f6eb3d-1.fc42.x86_64 from @System requires kernel-uname-r = 6.15.6-105.bazzite.fc42.x86_64, but none of the providers can be installed
Thank you!
hey, maybe it’s a silly question, but I wanted to ask before trying it myself in case it ends up going horribly wrong - would it be okay to run this kernel with nobara?
hey, I have a small question. Does this kernel updated in sync with cachyos kernel itself or in sync with fedoras kernel? 6.18.0 cachyos kernel is up but copr repo only has 6.17.9.
Hi,
I install this kernel in silerblue 43 but i dont found kernel-cachyis-headers. Is minnsing
rpm-ostree search kernel-cachyos
===== Name Matched =====
kernel-cachyos : Linux BORE Cachy Sauce Kernel by CachyOS with other patches and improvements.
kernel-cachyos-core : Linux BORE Cachy Sauce Kernel by CachyOS with other patches and improvements
kernel-cachyos-devel : Development package for building kernel modules to match kernel-cachyos
kernel-cachyos-devel-matched : Meta package to install matching core and devel packages for kernel-cachyos
kernel-cachyos-lts : Linux BORE Cachy Sauce Kernel by CachyOS with other patches and improvements.
kernel-cachyos-lts-core : Linux BORE Cachy Sauce Kernel by CachyOS with other patches and improvements
kernel-cachyos-lts-devel : Development package for building kernel modules to match kernel-cachyos-lts
kernel-cachyos-lts-devel-matched : Meta package to install matching core and devel packages for kernel-cachyos-lts
kernel-cachyos-lts-modules : Kernel modules package for kernel-cachyos-lts
kernel-cachyos-lts-nvidia-open : nvidia-open 590.44.01 kernel modules for kernel-cachyos-lts
kernel-cachyos-modules : Kernel modules package for kernel-cachyos
kernel-cachyos-nvidia-open : nvidia-open 590.44.01 kernel modules for kernel-cachyos
kernel-cachyos-rt : Linux BORE Cachy Sauce Kernel by CachyOS with other patches and improvements.
kernel-cachyos-rt-core : Linux BORE Cachy Sauce Kernel by CachyOS with other patches and improvements
kernel-cachyos-rt-devel : Development package for building kernel modules to match kernel-cachyos-rt
kernel-cachyos-rt-devel-matched : Meta package to install matching core and devel packages for kernel-cachyos-rt
kernel-cachyos-rt-modules : Kernel modules package for kernel-cachyos-rt
kernel-cachyos-rt-nvidia-open : nvidia-open 590.44.01 kernel modules for kernel-cachyos-rt
kernel-cachyos-server : Linux EEVDF scheduler Kernel by CachyOS targeted for Servers workloads
kernel-cachyos-server-core : Linux EEVDF scheduler Kernel by CachyOS targeted for Servers workloads
kernel-cachyos-server-devel : Development package for building kernel modules to match kernel-cachyos-server
kernel-cachyos-server-devel-matched : Meta package to install matching core and devel packages for kernel-cachyos-server
kernel-cachyos-server-modules : Kernel modules package for kernel-cachyos-server
kernel-cachyos-server-nvidia-open : nvidia-open 590.44.01 kernel modules for kernel-cachyos-server
Hello,
With the latest version scx_lavd is complaining about the kernel being compiled with pahole < 1.26 and it does not start:
These kfuncs are KF_IMPLICIT_ARGS but their public BTF prototype
still carries the implicit ‘struct bpf_prog_aux *’ argument, which
makes BPF programs fail to load with ‘func_proto incompatible with
vmlinux’. This happens when the kernel was built with pahole < 1.26.
Thank you!
Posting this in case others hit the same wall. Short version: the error message is misleading. It’s not really about your pahole version — it’s about which compiler built your kernel.
On Fedora 44 with kernel-cachyos (and also reproduced with the stock Fedora kernel, same result), trying to run scx_lavd (or presumably any scx_* scheduler using recent kfuncs) fails with:
Error: the running kernel's BTF has malformed scx kfunc prototype(s): __scx_bpf_dsq_insert_vtime, scx_bpf_cpu_curr, scx_bpf_cpuperf_cur, ...
These kfuncs are KF_IMPLICIT_ARGS but their public BTF prototype
still carries the implicit 'struct bpf_prog_aux *' argument...
Fix: boot a kernel whose BTF was generated with pahole >= 1.26.
pahole --version on the system was v1.30 — well above the 1.26 threshold the error message references. Reinstalling kernel-modules-extra, regenerating BTF from a debuginfo vmlinux with local pahole, even fully rebuilding the kernel from the matching .src.rpm with pahole 1.30 present at build time — none of it changed the outcome. The generated BTF for scx_bpf_kick_cpu (and the other kfuncs listed) always still carried the extra implicit aux (struct bpf_prog_aux *) argument in its FUNC_PROTO, confirmed directly via:
sudo bpftool btf dump file /sys/kernel/btf/vmlinux | grep -A4 "scx_bpf_kick_cpu"
Checked lib/Kconfig.debug in the matching kernel source tree:
config PAHOLE_HAS_BTF_TAG
def_bool PAHOLE_VERSION >= 123
depends on CC_IS_CLANG
PAHOLE_HAS_BTF_TAG — the config option that controls whether pahole is instructed to correctly encode/strip these implicit-argument kfunc prototypes — explicitly depends on CC_IS_CLANG. Both the stock Fedora kernel and kernel-cachyos (as shipped/built via the COPR) are built with GCC. Regardless of the pahole version present on the building machine, this Kconfig option silently stays disabled when the kernel is compiled with GCC, and the resulting BTF keeps the implicit argument — which is exactly what breaks scx_lavd (and likely other scx schedulers relying on KF_IMPLICIT_ARGS kfuncs) at load time.
Confirmed directly by rebuilding the same source tree, same .config, changing only the compiler:
cp /boot/config-<kernel-version> .config
make CC=clang LLVM=1 olddefconfig
scripts/config --file .config -s CC_IS_CLANG # -> y
scripts/config --file .config -s PAHOLE_HAS_BTF_TAG # -> y (was undef/n with GCC)
scripts/config --file .config -s DEBUG_INFO_BTF # -> y
With GCC (CC=gcc, the Fedora/CachyOS default), PAHOLE_HAS_BTF_TAG stays unset no matter the pahole version. With CC=clang LLVM=1, it flips to y immediately, using the exact same .config otherwise.
Rebuild the kernel with the LLVM/Clang toolchain instead of GCC:
make CC=clang LLVM=1 -j$(nproc)
make CC=clang LLVM=1 modules_install
make CC=clang LLVM=1 install
Clang/lld/llvm are already present as build dependencies for kernel-cachyos on Fedora (pulled in automatically via dnf builddep), so no extra packages are needed beyond what the src.rpm already requires.
Full end-to-end confirmation on a locally rebuilt kernel-cachyos (7.1.3-cachyos1.fc44 source, rebuilt with CC=clang LLVM=1, same .config as the shipped COPR kernel otherwise):
$ sudo scx_lavd --performance
...
2026-07-12T12:51:55Z INFO scx_lavd: capacity bound: ...
Error: another sched_ext scheduler is already running
$ cat /sys/kernel/sched_ext/state
enabled
(The “another sched_ext scheduler is already running” message is expected/benign here — it means a previous scx_lavd instance from testing was still attached; sched_ext/state showing enabled is the actual confirmation that the BPF scheduler loaded and is active.)
So, to summarize the full path from broken to working:
Root cause of the original KF_IMPLICIT_ARGS error: PAHOLE_HAS_BTF_TAG in lib/Kconfig.debug depends on CC_IS_CLANG. Both stock Fedora and kernel-cachyos (as shipped via COPR) are built with GCC, so this stays off regardless of pahole version, and the BTF for kfuncs like scx_bpf_kick_cpu keeps the implicit struct bpf_prog_aux * argument, which scx_lavd rejects at load time.
Fix: rebuild with CC=clang LLVM=1 instead of GCC. This alone fixes the KF_IMPLICIT_ARGS BTF mismatch completely (confirmed via bpftool btf dump — the implicit aux argument is gone from the kfunc prototypes after rebuilding with Clang).
New issue that showed up after switching to Clang (on the stock Fedora kernel rebuild specifically): scx_lavd then failed to load with a generic -EINVAL at BPF_PROG_LOAD time (no verifier instruction dump, so a different failure mode than the original BTF mismatch — likely something struct_ops/ABI related, never fully root-caused on that build).
On kernel-cachyos specifically (same Clang rebuild approach, same script, same .config philosophy — just against the CachyOS source instead of stock Fedora): that -EINVAL did not appear. scx_lavd --performance loaded and attached cleanly, sched_ext/state reports enabled. Whatever caused the -EINVAL on the stock kernel rebuild, kernel-cachyos’s source/config apparently avoids it — possibly related to CachyOS’s own BORE/scheduler-related config choices, though this wasn’t independently isolated; it’s just an empirical result of rebuilding both the same way and only one working.
Practical takeaway if you’re on kernel-cachyos and want to run scx_lavd (or likely other KF_IMPLICIT_ARGS-dependent scx_* schedulers): rebuilding the COPR kernel locally with CC=clang LLVM=1 gets you a fully working setup. It’d be worth the COPR maintainers considering building with Clang/LLVM by default, since the target audience (gaming/BORE/scx users) is exactly the group most likely to hit this.
Since kernel-cachyos targets users who often want the latest scx_* schedulers (BORE is already patched in, sched_ext is a natural pairing), it might be worth considering building the COPR kernel with CC=clang LLVM=1 by default, or at minimum documenting this dependency — otherwise PAHOLE_HAS_BTF_TAG silently stays off and any scx scheduler relying on these kfuncs fails with an error message that (misleadingly) points at the pahole version instead of the compiler.
System: Fedora 44, kernel-cachyos 7.1.3-cachyos1, pahole 1.30 (dwarves-1.30-3.fc44), clang 22.1.8