EEVDF Kernel on Omarchy

linux-omarchy-eevdf on Omarchy

linux-omarchy-eevdf is Omarchy's alternative kernel flavor (7.2.8-8) — the same Omarchy kernel patchset with the plain EEVDF CPU scheduler instead of the BORE/ADIOS-tuned default — for tinkerers who want to try stock scheduler behavior, benchmark against BORE, or bisect a scheduler-related problem. The companion package linux-omarchy-eevdf-headers holds the headers and build scripts DKMS modules need to compile against it.

TL;DR

omarchy pkg add linux-omarchy-eevdf
omarchy pkg add linux-omarchy-eevdf-headers  # only if you build DKMS modules

Install the EEVDF kernel, then select it in your bootloader at the next boot (it installs alongside your current kernel, it doesn't replace it). Takes a few minutes: 183.4 MB download. If you build out-of-tree modules (DKMS packages like the ThinkPad T14 touchpad driver), also install omarchy pkg add linux-omarchy-eevdf-headers.

Who this is for: people who know what a CPU scheduler is and want to try one. If that sentence doesn't describe you, stay on the default kernel — this package changes nothing you'll notice in a browser or terminal, and switching kernels is the one package install that can leave a machine unbootable if something goes wrong.

Getting started (15 minutes — includes a reboot)

1. Understand what you're choosing between.

Omarchy ships two kernel flavors, both built from the same Omarchy patchset (kernel 7.2.8). The default, linux-omarchy, is described in its PKGBUILD as "Omarchy Linux (BORE CPU scheduler, ADIOS I/O scheduler)": it carries the BORE patch (0110-bore-7.0.0 — Burst-Oriented Response Enhancer, which detects bursty interactive tasks and prioritizes them inside EEVDF) plus the ADIOS I/O scheduler (0150-adios-3.2.0), tuned to keep the desktop responsive under load. linux-omarchy-eevdf drops both of those and instead carries 0145-sched-eevdf-tunables — plain upstream EEVDF (Earliest Eligible Virtual Deadline First, the default Linux scheduler since 6.6, which replaced CFS) with Omarchy's tunables and the rest of the Omarchy patchset (Btrfs, AMD display, sound, power-management fixes, etc.). Think of it as the "control group" kernel: same Omarchy fixes, stock scheduling philosophy.

2. Install.

omarchy pkg add linux-omarchy-eevdf. The install generates the initramfs for the new kernel release (7.2.8-8-omarchy-eevdf per the PKGBUILD's localversion files — confirm on-machine). Your current kernel stays installed and stays the default; the new kernel just adds a boot entry.

3. Select it at boot.

Reboot and pick the new entry in the bootloader (Omarchy uses limine — confirm the entry naming and how to change the default in the checklist above). Verify with uname -r: you should see the -omarchy-eevdf release string instead of -omarchy.

4. Install the headers if you need them.

omarchy pkg add linux-omarchy-eevdf-headers. You need this package (345.4 MB installed) only if you compile out-of-tree kernel modules — i.e. you use a DKMS package. The canonical example on this site: thinkpad-t14-amd-touchpad-dkms rebuilds its i2c-piix4, rmi_smbus, and psmouse modules via DKMS, and DKMS compiles against the headers of the kernel you're installing for. No DKMS packages, no headers needed. The headers package provides LINUX-HEADERS and symlinks /usr/src/linux-omarchy-eevdf to the build tree, and the kernel package lists it as an optdepend ("headers and scripts for building modules") — along with scx-scheds if you want to experiment with sched_ext schedulers on top.

5. The three things everyone needs to know:

• The two kernels coexist. Installing eevdf doesn't remove linux-omarchy. If the eevdf kernel misbehaves, reboot and pick your old entry — you always have a way back. (Confirm the default-entry behavior on-machine before publishing.)
• DKMS modules are per-kernel. A DKMS package built against linux-omarchy-headers is not built for the eevdf kernel until its headers are installed and the DKMS hook rebuilds. After installing both, run the relevant check tool (e.g. thinkpad-t14-amd-touchpad-check) while booted into the eevdf kernel to confirm the modules actually built for it.
• Expect no fireworks. EEVDF vs BORE differences show up under mixed load (compiling while playing audio, heavy multitasking) and in benchmarks, not in idle desktop feel. If you're trying this to fix a specific stutter, measure before and after — don't go by vibes.

Common issues & fixes

No user-reported issues exist yet for this specific package (it appeared on the app store 2026-10-18). The items below are grounded in the PKGBUILD contents, the sibling touchpad-driver repo's documented DKMS behavior, and standard Arch kernel practice — marked where they're general practice rather than package-specific reports. Nothing here is claimed as reproduced.

You installed it, rebooted, and uname -r still shows the old kernel

Installing a kernel package only adds a boot entry — it doesn't change which entry boots by default. General Arch behavior, not package-specific.

Fix: Reboot, open the bootloader menu (Omarchy uses limine), and select the eevdf entry explicitly. If you want it as the default, change the default in the limine configuration (verify exact steps on-machine — marked unverified).

A DKMS package (e.g. the ThinkPad touchpad driver) stopped working after you switched to the eevdf kernel

DKMS builds modules per kernel release, and it needs the matching headers.

Fix: Install omarchy pkg add linux-omarchy-eevdf-headers, then trigger a rebuild (reinstall the DKMS package), then run its check tool while booted into the eevdf kernel. The touchpad repo documents the failure mode precisely: if the DKMS build fails, the stock modules load and the hardware silently falls back to its unpatched behavior — the check tool is how you notice. (From orospakr/thinkpad-t14-amd-touchpad README; applies to any DKMS module on any kernel flavor.)

You're not sure the scheduler actually changed

Compare uname -r output (-omarchy vs -omarchy-eevdf) and inspect the scheduler tunables the eevdf patch exposes (patch 0145-sched-eevdf-tunables — exact paths to be confirmed on-machine in the checklist).

Fix: For a behavioral check, BORE's whole point is prioritizing bursty interactive tasks under background load; a compile-while-playing-audio test is the classic discriminator, but quantify it rather than eyeballing it.

Disk space jumped by ~530 MB

Expected: the kernel is 183.5 MB installed and the headers are 345.4 MB installed (app-store package details, 7.2.8-8).

Fix: If you don't build modules, skip the headers package. If you abandon the experiment, remove both packages and the boot entry goes with them (confirm on-machine).

You want to go back to the default kernel permanently

Reboot into the linux-omarchy entry, then remove the eevdf packages (omarchy pkg remove linux-omarchy-eevdf linux-omarchy-eevdf-headers — confirm exact remove syntax on-machine). Your original kernel and its entry are untouched by the whole experiment, since the packages never replaced anything.

Pairs well with / If you hate this, try

Pairs well with

• thinkpad-t14-amd-touchpad-dkms — the DKMS touchpad driver is the most concrete reason to care about the headers package; its guide covers the per-kernel rebuild dance. scx-scheds (listed as an optdepend in the PKGBUILD) if you want to experiment with sched_ext schedulers, which is the deeper end of the same pool.

If you hate this, try

• Staying on linux-omarchy — the BORE/ADIOS default is what the Omarchy team tunes and tests, and it's the kernel the 4.0.4 release made the default boot option. Or the stock Arch linux package if you want zero Omarchy patches at all.

Comparison: Omarchy kernel flavors

Verdict: Install the eevdf flavor if you want the control group — same Omarchy fixes, stock scheduling behavior, easy A/B against BORE. Everyone else should stay on the default.