rmnscnce/kernel-xanmod

Description

XanMod is a general-purpose Linux kernel distribution with custom settings and new features. Built to provide a stable, responsive and smooth desktop experience.

The real-time version is recommended for critical runtime applications such as Linux gaming eSports, streaming, live productions and ultra-low latency enthusiasts.

Supports all recent 64-bit versions of Fedora Linux.

※ RT builds are currently unavailable

Main features

  • Preemptive Full Tickless Kernel at 500Hz w/ Tuned CPU Core Scheduler.
  • RCU Boost for better responsiveness and lower overall system latency.
  • Full multi-core block layer runqueue requests for high I/O throughput.
  • Caching, Virtual Memory Manager and CPUFreq Governor improvements.
  • BBR TCP Congestion Control + FQ-PIE Packet Scheduling and AQM Algorithm
  • ORC Unwinder for Kernel Stack Traces (debuginfo) implementation
  • Third-party patchset available: Futex2 interface [5.11], BBRv2 TCP congestion [5.11][5.10][as module], ZSTD kernel modules support [5.11][5.10], Clear Linux [partial], CK's Hrtimer patchset, Futex Proton Fsync support, PCIe ACS Override [5.11][5.10], Aufs [5.4] and Graysky's GCC patchset.
  • High responsiveness multitasking CacULE scheduler (SCHED_NORMAL) based on ULE interactivity score mechanism build available
  • GPLv2 license. Can be built for any distribution or purpose.

Installation Instructions

sudo dnf enable rmnscnce/kernel-xanmod

Active Releases

The following unofficial repositories are provided as-is by owner of this project. Contact the owner directly for bugs or issues (IE: not bugzilla).

* Total number of packages downloaded in the last seven days.


This is a companion discussion topic for the original entry at https://copr.fedorainfracloud.org/coprs/rmnscnce/kernel-xanmod/

I was just looking into trying to compile the RT on Fedora 33. Is the lack of RT here temporary and just needs work, or are there some specific issues with it?

consider update the dependencies/requirements to follow fedora upstream?

I don’t think tracking requirements with upstream is necessary, especially considering how the RPM spec file is not the same as the one on Fedora upstream. One small goal of my kernel projects is to provide easy to use, non-spaghetti kernel RPM spec file for hobbyists and tinkerers alike. The one on Fedora’s kernel SRPM is too complex, in my opinion

how to solve this problem?

See the header on the Copr page:

Basically you need to remove the outdated kernel-xanmod-cacule from the Fedora kernel and then reinstall the new one from there. I’m sorry for the breaking changes, but this had to be done.

(The new changes makes it possible to update kernel-xanmod packages easily without updating the -devel packages first, making the experience closer to the stock Fedora distro kernel)

I am getting the following during boot on an up to date Fedora 34 and then it returns to grub menu:

error: …/…/grub-core/kern/efi/sb.c:151:bad shim signature.
error: …/…/grub-core/loader/i386/efi/linux.c:208:you need to load the kernel first.

The message seems to be related to this patch:
https://lists.gnu.org/archive/html/grub-devel/2018-10/msg00009.html

Not sure if it makes a difference, but the pc is an HP Elitedesk with “HP Sure Boot Secure Boot Keys Protection” enabled. What it does is explained here: http://h10032.www1.hp.com/ctg/Manual/c06216928

I’d like to keep the setting enabled so is it possible to fix this in the code? Should I file a bug in the upstream?

@rmnscnce Thank you for packaging the Xanmod kernel, I’ve been using this copr without issues for some time.

Just something strange I noticed is that I always get these files in the root directory as soon as a new kernel is installed:
$ ls -l /xan
-rw-------. 1 root root 76591421 25. Mai 10:40 /5.12.6-xanmod1.3.fc34
-rw-------. 1 root root 77015936 30. Mai 17:54 /5.12.8-xanmod1.0.fc34

Is that intentional? They’re not deleted when the package is removed, and dnf whatprovides can’t find the package they belong to.

Those files contain microcode firmware in CPIO format

I had those pruned at first but then I thought it might be helpful. I may be wrong though

Apparently the cacule kernel is not compatible with akmod-nvidia too

This is a known issue. I’ll try to fix them on the next release

Great ! Sorry I’m not too used to the fedora web site and didn’t even know there was an issue tracker.

There’s another thing that I noticed, there is a bit of a weird dependencies behaviour : if I enable the copr then just do a dnf up, it wants to install kernel-xanmod-edge-headers to replace the kernel-headers package. Thoses 2 can’t get along ?

Yeah, those two cannot get along since they have same files in /usr/include. I made it to avoid conflicts

If you once will drop XanMod and use the Fedora kernel builds again, you can do sudo dnf swap kernel-\*-headers kernel-headers

For some reason which I have been unable to determine, every time I try to use any of the packages in this repo, I get booted into an emergency shell that isn’t able to load /bin/bash or /bin/sh to troubleshoot anything. The output before the emergency shell prompt says that /boot/efi could not be mounted… It’s very confusing. I have made slight adjustments to my /etc/fstab to use Timeshift for btrfs backups and I’m using self-compiled TKG kernels if that makes any difference, but I don’t see how those would…

Since 5.12.10-xm1.0, I’m only able to boot this kernel with selinux=0. Otherwise I get a lot of failing systemd service, no shell whatsoever, Ctrl-Alt-Del complains about being unable to execute the shutdown binary file. Systemd’s rescue & emergency targets also didn’t work with SELinux enabled.

SELinux is working well on my installation of kernel-xanmod-exptl version 5.12.12-xm1.0e20210611 (Clang+LTO is great!)

The SELinux problem was caused by missing SELinux defaults on (only) 5.12.9 series that makes relabeling required on the machine. Try marking the system for a full auto relabeling (touch /.autorelabel) and reboot into SELinux permissive mode (append enforcing=0 at the kernel command line)

Sorry for the inconveniences caused by the undocumented bug. I should have filed a ticket in the packaging issue tracker

```
rmnscnce

That worked for me, thank you very much!

1 Like

I’ve been meaning to ask, because I’d like to help the linux-tkg folks figure out a solution to this problem: how did you get akmods to compile for your custom kernels? Right now they always fail on any linux-tkg compile kernel with an error about missing a description in the spec, but it appears that you’ve solved that issue for all of your xanmod versions.

I currently have 2 kernel variants that require some tweaks to have akmods working sucessfully every time: kernel-xanmod-cacule and kernel-xanmod-exptl, but as you asked about this:

so I’ll just mention the CacULE variant.


For kernel-xanmod-cacule, the problem was that akmods can’t build due to “missing %description”. Fixed by this resolution. The problem? “Exotic characters” in the kernel version string, and kmodtool doesn’t like it. Do not have any padding characters inside that part of the kernel string (or any part, to be safe)

```
rmnscnce

Would it be possible to remove grubby as a dependency for the kernel packages?
grub and grubby are not dependencies for the regular Fedora kernels, and I don’t see why they would be needed for xanmod either. I use systemd-boot, so grub gets installed for no reason.

1 Like