From Fedora Project Wiki

No edit summary
No edit summary
Line 49: Line 49:
| …, 6.1-rc8-202212111, 6.1, 6.2-rc0-202212113, 6.2-rc0-202212114, 6.2-rc0-202212115, …
| …, 6.1-rc8-202212111, 6.1, 6.2-rc0-202212113, 6.2-rc0-202212114, 6.2-rc0-202212115, …
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|colspan="4"| '''Note''': each repository mentioned above includes all the ones mentioned earlier as runtime dependency. Users of the ‘stable-rc’ repository thus will receive packages from the ‘stable’ or ‘fedora’ repositories when they ship kernel packages which package managers will consider newer; this will ensure stable-rc users won’t be stuck on a kernel with known problems that were fixed between the release of the rc and the final version.
|colspan="4"| '''Note''': each of those repository includes all the ones mentioned above it as runtime dependency. Users of the ‘stable-rc’ repository thus will receive packages from the ‘stable’ or ‘fedora’ repositories when they ship kernel packages which package managers will consider newer; this will ensure stable-rc users won’t be stuck on a kernel with known problems that were fixed between the release of the rc and the final version.
<br>
<br>
Also, be aware that these repositories intend to never provide kernels older than those the particular Fedora release uses by default, as that could lead to problems. That aspect is mainly relevant for Fedora versions in development (IOW: rawhide and beta releases). Rawhide for example regularly uses the latest mainline builds; that’s why users of rawhide that have one of these repos enabled will receive vanilla mainline builds all the time, even if they chose the ‘stable’ or ‘mainline-wo-mergew’ repos. Users of pre-releases like a beta might see similar effects (but won’t get kernels from the merge window, unless the beta includes them, which would be quite unusual). Once a Fedora version under development gets closer to its final release everything will start to work as advertised.
Also, be aware that none of these repositories will provide kernels older than those the particular Fedora release uses by default, as that could lead to problems. That aspect is mainly relevant for Fedora versions in development (IOW: rawhide and beta releases). Rawhide for example regularly uses the latest mainline builds; that’s why users of rawhide that have one of these repos enabled will receive vanilla mainline builds all the time, even if they chose the ‘stable’ or ‘mainline-wo-mergew’ repos. Users of pre-releases like a beta might see similar effects (but won’t get kernels from the merge window, unless the beta includes them, which would be quite unusual). Once a Fedora version under development gets closer to its final release everything will start to work as advertised.
|}
|}



Revision as of 20:09, 17 January 2023

Linux kernel vanilla repositories for Fedora Linux

The kernel vanilla kernel repositories allow you to quickly, comfortably, and cleanly install the latest Linux kernels on Fedora Linux. Versions from various Linux series are available, among them: the latest ‘mainline’ kernel, the newest ‘stable’ release, or the latest version from the kernel series currently used by Fedora Linux. These kernels are perfect for both quick tests and regular day-to-day use.

How to install a vanilla kernel from these repositories

If you’re on a x86 system, first run mokutil --sb-state to check whether UEFI Secure Boot is active on your system. If that’s the case you have to turn it off either in your BIOS Setup or through a process initiated with mokutil --disable-validation; do not omit this, as the kernels from these repositories won’t boot otherwise, because they are not signed with a key typical x86 systems trust.

Now enable one of the kernel vanilla repositories and update your system. The following commands for example will install the latest mainline kernel:

sudo dnf -y copr enable @kernel-vanilla/mainline 
sudo dnf update 'kernel*'

In case you want that vanilla kernel just for a quick test, run sudo dnf copr remove thl/kernel-vanilla-mainline right afterwards to remove the repository again. Later when you’ve finished your tests, reboot and choose the latest stock Fedora Linux kernel from the boot menu; then uninstall all packages from the kernel vanilla repositories using sudo dnf remove $(rpm -qa 'kernel*' | grep '.vanilla' ) to ensure retrieving kernel updates from Fedora again.

Linux kernels series offered in the repositories

repository description target users example version sequence
fedora vanilla kernels from the stable series the latest Fedora Linux currently uses anyone who wants to check if vanilla kernels shows the same bug or behavior as the latest Fedora kernel …, 6.0.18, 6.0.19, 6.1.5, 6.1.6, …
stable the latest stable kernel according to the frontpage of kernel.org; this repo thus won't ship mainline releases like 6.1 and only jumps to a newer series once its first stable release (e.g. 6.1.1) is published anyone who wants the latest Linux stable kernel …, 6.0.14, 6.0.15, 6.1.1, 6.1.2, 6.1.3, …
stable-rc pre-releases of the next stable release anyone who wants to help testing future Linux stable kernels …, 6.0.14, 6.0.15-rc1, 6.0.15, 6.1.1-rc1, 6.1.1, …
mainline-wo-mergew identical to the ‘mainline’ repositories, but steers clear of git snapshots during merge windows anyone who normally wants the latest mainline kernel, but wants to play it a bit safer by avoiding mainline during merge windows; that's the phase at the beginning of a development cycle where the bulk of changes (~85 percent) are merged for the next mainline release before its first pre-release (e.g. a “-rc1") is published …, 6.1-rc8-202212111, 6.1, 6.1.1-rc1, 6.1.1, 6.2-rc1, 6.2-rc1-202212126, 6.2-rc1-202212113, …
mainline mainline kernels, either built from a proper release, a pre-release (aka "rc kernel"), or a git snapshot anyone who wants to run a kernel built from the the latest Linux codebase …, 6.1-rc8-202212111, 6.1, 6.2-rc0-202212113, 6.2-rc0-202212114, 6.2-rc0-202212115, …
Note: each of those repository includes all the ones mentioned above it as runtime dependency. Users of the ‘stable-rc’ repository thus will receive packages from the ‘stable’ or ‘fedora’ repositories when they ship kernel packages which package managers will consider newer; this will ensure stable-rc users won’t be stuck on a kernel with known problems that were fixed between the release of the rc and the final version.


Also, be aware that none of these repositories will provide kernels older than those the particular Fedora release uses by default, as that could lead to problems. That aspect is mainly relevant for Fedora versions in development (IOW: rawhide and beta releases). Rawhide for example regularly uses the latest mainline builds; that’s why users of rawhide that have one of these repos enabled will receive vanilla mainline builds all the time, even if they chose the ‘stable’ or ‘mainline-wo-mergew’ repos. Users of pre-releases like a beta might see similar effects (but won’t get kernels from the merge window, unless the beta includes them, which would be quite unusual). Once a Fedora version under development gets closer to its final release everything will start to work as advertised.

Linux kernel versions currently offered

Look at the file repostatus.txt or execute the following script to query the latest packages locally:

dists=(36 37 rawhide)
dnf clean all > /dev/null
for repo in fedora stable{,-rc} mainline{-wo-mergew,}; do
	repostring="${repostring} --repofrompath=kvr-${repo},https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/${repo}/fedora-\${distro}-x86_64/"
	for distro in ${dists[*]} ; do
		queryresult="$(eval dnf repoquery ${repostring} --disablerepo=* --enablerepo=kvr-* --latest-limit=1 -q kernel --arch x86_64 --qf '%{version}-%{release}')"
  		printf '%-20s %-10s %s\n' ${repo} ${distro} ${queryresult:-lookup failed}
	done
done

How vanilla kernels compare to Fedora’s

Most of the time these kernels will work roundabout as well and secure as Fedora’s. Sometimes though the kernels from these repositories will work better, as they contain drivers or security fixes that haven’t reached the kernels used by Fedora Linux yet; but then again other times it’s just the other way around.

Developers behind the effort

The kernel vanilla repositories are maintained primarily by Thorsten Leemhuis (aka "knurd"); the SRPMs are pretty close to those used to build Fedora’s kernel, but its maintainers are not involved in the maintenance of these repositories.

Why some repositories look unmaintained

Quite a few of the repositories will look outdated, abandoned, or even empty when you check for recent builds in copr’s web interface or look straight at a repository. But be assured, most likely everything is well. It will look like that when the most recent build suitable for users of that repository is found in one of the other repositories included as a runtime dependency (see the footnote in above table for details).

What’s the goal of these repositories? And are these kernels as good as Fedora’s?

These and many other questions are answered in the FAQ about the Linux kernel vanilla repositories for Fedora Linux.

Point of contact

For any feedback or questions regarding the kernel vanilla repositories contact Thorsten Leemhuis (aka "knurd").