How to Install Kernel Vanilla Mainline on Fedora 44

Installing a mainline or vanilla Linux kernel on Fedora makes sense when you need to test upstream fixes before Fedora carries them or confirm whether a hardware or regression issue comes from Fedora’s patch set. Kernel Vanilla COPR repositories provide Fedora-built packages from upstream Linux kernel branches, including stable, release-candidate, mainline, and linux-next builds.

Use these repositories as a testing or troubleshooting path, not as a drop-in support replacement for Fedora’s kernel. Keep at least one Fedora kernel installed, review each DNF transaction before continuing, and check the Kernel Vanilla repository status file when you need the current version for a specific COPR.

Install Mainline or Vanilla Linux Kernel on Fedora

Choose a Kernel Vanilla COPR

The Kernel Vanilla repositories currently publish seven COPRs. For mainline testing, @kernel-vanilla/mainline-wo-mergew is the safer default because it avoids the early merge-window snapshots. For a released upstream kernel, choose @kernel-vanilla/stable or @kernel-vanilla/fedora depending on whether you want the newest stable branch or the branch Fedora is already using or about to receive.

This workflow installs prebuilt RPM packages through DNF. It does not compile a kernel from source or install a manually downloaded kernel.org tarball.

COPR	Kernel stream	Best for	Update behavior
@kernel-vanilla/mainline-wo-mergew	Mainline, paused during merge windows	Testing the latest upstream mainline code with less merge-window churn	Frequent builds after the first release candidate appears
@kernel-vanilla/mainline	Mainline snapshots, including merge-window code	Developers who deliberately want the newest daily upstream snapshots	Frequent builds, including riskier early-cycle snapshots
@kernel-vanilla/next	linux-next	Testing changes queued for the next mainline cycle	Daily or near-daily linux-next builds when available
@kernel-vanilla/stable	Latest stable upstream kernel for regular users	Running the newest released upstream stable kernel	Updates after upstream stable releases
@kernel-vanilla/stable-rc	Stable release candidates	Testing upcoming stable point releases before they are final	Updates when stable release candidates appear
@kernel-vanilla/fedora	Latest upstream version from Fedora’s current or near-future kernel series	Checking whether a bug exists in upstream without jumping to a different kernel branch	Updates close to Fedora’s current kernel series
@kernel-vanilla/fedora-rc	Release candidates for Fedora’s current or near-future kernel series	Testing fixes likely to land soon in Fedora’s kernel stream	Updates when Fedora-series release candidates appear

Only @kernel-vanilla/fedora and @kernel-vanilla/next are standalone. Other Kernel Vanilla COPRs can depend on lower-risk repositories so DNF can select the newest suitable build across the dependency chain. When DNF asks to enable dependent COPRs, review the list and continue only if it matches the Kernel Vanilla sources you intended to use.

Check Secure Boot Before Installing

Typical x86_64 UEFI Secure Boot setups do not trust Kernel Vanilla kernels out of the box. Install mokutil if needed, then check whether Secure Boot is enabled before installing a kernel that might not boot on your system.

sudo dnf install mokutil
mokutil --sb-state

Expected output when Secure Boot is enabled:

SecureBoot enabled

If Secure Boot is enabled, disable it in your UEFI firmware before booting a Kernel Vanilla package, or follow Fedora’s upstream-kernel documentation to sign the kernel with your own Machine Owner Key. If mokutil reports that EFI variables are not supported, the current boot environment cannot prove Secure Boot state.

Firmware menus differ by hardware vendor. The usual path is to restart, open UEFI setup with the vendor boot key, find Secure Boot under a Security, Boot, or Authentication menu, disable it, then save and restart.

Disabling Secure Boot reduces protection against boot-time malware. Re-enable it after you return to Fedora’s signed kernel path, or use a validated MOK signing workflow if Secure Boot must remain part of your system policy.

Update Fedora Before Adding the Kernel COPR

Refresh Fedora first so the new kernel is compared against the latest stock packages, not stale local metadata.

sudo dnf upgrade --refresh

Reboot first if the update installs a new Fedora kernel. Starting from a known-good Fedora kernel makes it easier to recover if the vanilla build does not boot.

Enable the Kernel Vanilla COPR

Enable the COPR that matches the kernel stream you chose. The mainline example uses @kernel-vanilla/mainline-wo-mergew.

sudo dnf copr enable @kernel-vanilla/mainline-wo-mergew

DNF prints Fedora’s COPR warning and, for this mainline COPR, a dependency list. The dependency section should name Kernel Vanilla repositories such as fedora, fedora-rc, stable, and stable-rc.

Maintainer of the enabled Copr repository decided to make
it dependent on other repositories.

  1. [coprdep:copr.fedorainfracloud.org:group_kernel-vanilla:fedora]
  2. [coprdep:copr.fedorainfracloud.org:group_kernel-vanilla:fedora-rc]
  3. [coprdep:copr.fedorainfracloud.org:group_kernel-vanilla:stable]
  4. [coprdep:copr.fedorainfracloud.org:group_kernel-vanilla:stable-rc]

These repositories are being enabled together with the main repository.

Use a different COPR name when you want another stream. Choose one command, not all three.

sudo dnf copr enable @kernel-vanilla/stable

sudo dnf copr enable @kernel-vanilla/fedora

sudo dnf copr enable @kernel-vanilla/next

Run only one of those commands unless you intentionally want to change streams. Mixing Kernel Vanilla COPRs without a reason makes later cleanup and package-source checks harder.

Install the Vanilla Kernel Packages

Upgrade the installed kernel package family from the enabled COPR. DNF may also upgrade related packages such as kernel-tools and remove the oldest installed kernel to honor Fedora’s install-only package limit.

sudo dnf upgrade 'kernel*' --refresh

Review the transaction before accepting it. A current Fedora 44 mainline transaction installs packages such as kernel, kernel-core, kernel-modules, kernel-modules-core, kernel-modules-extra, kernel-tools, and kernel-tools-libs from the Kernel Vanilla COPR. Systems that already have development, header, real-time, debug, or other kernel-family packages installed can show additional matching packages in the same transaction.

Reboot into the Vanilla Kernel

Reboot after the package transaction completes.

sudo reboot

After Fedora starts again, verify the active kernel. Kernel Vanilla builds include .vanilla in the release string.

uname -r

Example output from Fedora 44 with the mainline-wo-mergew COPR:

7.1.0-0.rc3.260516.6916d570.326.vanilla.fc44.x86_64

The exact number changes often. For stable COPRs, expect a released version such as 7.0.8-300.vanilla.fc44; for mainline COPRs, release-candidate or daily snapshot strings such as 7.1.0-0.rc3 are normal.

Install Matching Kernel Development Files When Needed

The main kernel upgrade does not necessarily install kernel-devel. Install the matching development package after booting the vanilla kernel when DKMS, VirtualBox, NVIDIA, or another external module workflow needs headers and build files for the running kernel.

sudo dnf install "kernel-devel-$(uname -r)"

Verify that the matching development tree exists:

test -d "/usr/src/kernels/$(uname -r)" && echo "kernel-devel matches the running kernel"

kernel-devel matches the running kernel

Restore the Default Fedora Kernel

Restore Fedora’s kernel when the vanilla build does not solve the issue, breaks hardware, or is no longer needed. The safest order is to remove the COPR source, synchronize related packages back to Fedora, boot a Fedora kernel, and then remove remaining vanilla kernel packages.

Remove the Kernel Vanilla COPR

Remove the COPR that you enabled. If you used the mainline example, run:

sudo dnf copr remove @kernel-vanilla/mainline-wo-mergew

List enabled COPRs when you need to confirm the exact Kernel Vanilla stream name first:

dnf copr list

Synchronize Kernel-Related Packages to Fedora

Synchronize installed kernel-related package names back to Fedora’s repositories. This wider package list catches package surfaces that can follow the Kernel Vanilla source, including kernel-tools, kernel-headers, libperf, perf, python3-perf, rtla, and rv when they are installed.

mapfile -t kernel_packages < <(rpm -qa 'kernel*' 'libperf*' perf python3-perf rtla rv --qf '%{name}\n' | sort -u)

if [ "${#kernel_packages[@]}" -gt 0 ]; then
    sudo dnf --refresh distro-sync "${kernel_packages[@]}"
else
    echo "No kernel-related packages were found."
fi

Review the transaction before accepting it. If you installed vanilla development files, DNF may replace them with Fedora’s matching kernel-devel package.

Set Fedora’s Kernel as the Next Boot Entry

Use GRUB manually if you prefer: reboot, open the boot menu, and select the newest Fedora kernel entry that does not contain .vanilla. To set that choice from the terminal instead, resolve the newest non-vanilla kernel-core package and pass it to grubby.

stock_kernel=$(rpm -qa 'kernel-core*' | grep -v '\.vanilla' | sed 's/^kernel-core-//' | sort -V | tail -n 1)

if [ -n "$stock_kernel" ]; then
    sudo grubby --set-default "/boot/vmlinuz-${stock_kernel}"
else
    echo "No Fedora kernel-core package was found."
fi

Reboot and confirm the active kernel no longer contains .vanilla.

sudo reboot

uname -r

7.0.8-200.fc44.x86_64

Remove Remaining Vanilla Kernel Packages

After you are running a Fedora kernel, remove remaining packages whose installed release contains .vanilla.

rpm -qa 'kernel*' 'libperf*' perf python3-perf rtla rv | grep '\.vanilla' | xargs -r sudo dnf remove

Verify that no Kernel Vanilla packages remain:

rpm -qa 'kernel*' 'libperf*' perf python3-perf rtla rv | grep vanilla

No output means the vanilla packages are gone.

Manage Installed Kernels on Fedora

Fedora keeps multiple install-only kernel versions so you can boot a previous kernel after a bad update. Do not remove every fallback kernel immediately after installing a vanilla build.

List Installed Kernel Images

List installed kernel images with their package releases:

rpm -qa 'kernel-core*' | sort -V

Example output with two Fedora kernels and one Kernel Vanilla mainline kernel installed:

kernel-core-7.0.6-200.fc44.x86_64
kernel-core-7.0.8-200.fc44.x86_64
kernel-core-7.1.0-0.rc3.260516.6916d570.326.vanilla.fc44.x86_64

Remove Older Install-Only Kernels

Use DNF5’s install-only cleanup instead of hand-building a removal list. Keeping two versions gives you the running kernel plus one fallback.

sudo dnf remove --oldinstallonly --limit=2

Keep at least one known-working Fedora kernel until the vanilla kernel has survived the workload you installed it to test. Removing every fallback can leave recovery dependent on rescue media or snapshots.

Troubleshoot Kernel Vanilla on Fedora

System Boots the Fedora Kernel Instead of the Vanilla Kernel

If Fedora continues booting the stock kernel, list the boot entries and check whether the vanilla entry exists.

sudo grubby --info=ALL | grep -E '^(index|title|kernel)='

Set the vanilla entry manually only after confirming the path exists under /boot.

vanilla_kernel=$(rpm -qa 'kernel-core*' | grep '\.vanilla' | sed 's/^kernel-core-//' | sort -V | tail -n 1)

if [ -n "$vanilla_kernel" ]; then
    sudo grubby --set-default "/boot/vmlinuz-${vanilla_kernel}"
else
    echo "No Kernel Vanilla kernel-core package was found."
fi

System Fails to Boot with the Vanilla Kernel

Restart and open the GRUB menu with Esc, Shift, or the firmware-specific boot-menu key. Select a Fedora kernel entry that does not contain .vanilla, then follow the restore workflow after Fedora starts.

GRUB Does Not Show Kernel Options

If GRUB hides the menu, clear the auto-hide flag and reboot.

sudo grub2-editenv - unset menu_auto_hide

Secure Boot Prevents the Vanilla Kernel from Starting

A Secure Boot violation usually means the firmware rejected the unsigned or untrusted vanilla kernel path. Boot a Fedora kernel, then either disable Secure Boot before trying again or use a complete MOK signing workflow from Fedora’s upstream-kernel documentation.

Akmods, DKMS, or Third-Party Modules Are Missing

External modules need build files for the active kernel. Install the matching development package before rebuilding modules for NVIDIA drivers on Fedora, VirtualBox, or another akmods or DKMS workflow.

sudo dnf install "kernel-devel-$(uname -r)"

Then run the rebuild command for the module system your driver uses. Fedora RPM Fusion driver packages commonly use akmods; manual or vendor module workflows may use DKMS.

if command -v akmods >/dev/null 2>&1; then
    sudo akmods --force
fi

if command -v dkms >/dev/null 2>&1; then
    sudo dkms autoinstall
fi

If the development package is missing, confirm that the Kernel Vanilla COPR you used is still enabled. Fedora’s normal kernel headers and kernel-devel package workflow applies only to Fedora’s stock kernel packages unless the alternate kernel source provides matching packages.

Conclusion

Fedora is running a Kernel Vanilla build when uname -r shows .vanilla, and the stock Fedora kernel remains available as a fallback. Keep the COPR enabled only while you want updates from that stream, install matching development files for module builds, and restore Fedora’s packages before removing the last known-good Fedora kernel.