Hi.
unfortunately we have issues with uksmd-lts on f39 because of dependencies versions.
uksmd-rawhide is the same as uksmd, though its a newer version and works for the stable kernel.
are you on the LTS kernel?
6.6 will become the new LTS kernel later this month or early next month. And then uksmd-rawhide can be used with LTS too.
The new cachyos-settings has file conflict with my nvidia driver packages from negativo17, specifically the file /usr/lib/modprobe.d/nvidia.conf from the nvidia-kmod-common package.
Just for reference this is the content of the exisiting (nvidia-kmod-common) package:
# Nouveau must be blacklisted here as well beside from the initrd to avoid a
# delayed loading (for example on Optimus laptops where the Nvidia card is not
# driving the main display).
blacklist nouveau
# Make a soft dependency for nvidia-uvm as adding the module loading to
# /usr/lib/modules-load.d/nvidia-uvm.conf for systemd consumption, makes the
# configuration file to be added to the initrd but not the module, throwing an
# error on plymouth about not being able to find the module.
# Ref: /usr/lib/dracut/modules.d/00systemd/module-setup.sh
# Even adding the module is not the correct thing, as we don't want it to be
# included in the initrd, so use this configuration file to specify the
# dependency.
softdep nvidia post: nvidia-uvm
# Enable complete power management. From:
# file:///usr/share/doc/nvidia-driver/html/powermanagement.html
options nvidia NVreg_DynamicPowerManagement=0x02
options nvidia NVreg_EnableS0ixPowerManagement=1
options nvidia NVreg_PreserveVideoMemoryAllocations=1
Hi, recent commit was merged that fixes this conflict by renaming nvidia.conf from our package to nvidia_cachyos.conf. The package should be rebuilt soon in the copr so stay tuned.
Hey, I have noticed that all the lto cachyos kernels(lts and non-lts) that support scx scheduler aren’t booting when scx.service is enabled. Is this a known issue? Otherwise I could help with some logs. I wonder if there is a convenient way to toggle scx from grub instead of systemD as a service)
Hello, are u on Fedora Rawhide? scx support was disabled on kernel-cachyos-lto rawhide due to broken pahole. LTS doesn’t support scx so the service is likely on a retry loop, causing boot to fail.
No, I am using fedora 40 with some upstream packages(unlikely to cause this issue). I have a older LTS LTO cachy kernel that boots just fine with scx.service enabled as it can’t find scx support on the kernel so the service fails to start and I was able to see it in the journalctl log. Maybe it’s conflicting with an existing service like ananicy-cpp?
For the time being I suggest to add some delay to scx.service to prevent it from causing such issues(the service should start once the system is up and running so that it can fail gracefully without getting stuck during the boot). As I feel splitting scx package further into LTS may cause confusion for people who have both lts and non lts version installed.
After a bit of investigation, it doesn’t seem like this issue is caused by the scx service. scx/services/systemd/scx.service at main · sched-ext/scx · GitHub If you look here there is “ConditionPath” which checks if the kernel has sched-ext support or not. If it doesn’t, the service will simply not start.
scx-scheds service won’t start on my system
kernel: 6.10.9-cb1.0.lto
scx-sched-git: scx-scheds-git-1.0.4-2.20240907.git.17e0e08
error: scx.service - Start scx_scheduler was skipped because of an unmet condition check
in fact the directory /sys/kernel/sched_ext doesn’t exists on my system, am I missing something?