From Fedora Project Wiki

(some details about bugs)
 
(198 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{admon/warning|This is a draft document that describes a package repository that is neither announced not ready for public consumption, as some of the details might change during the boot-up-phase the repositories are in at the moment. And this page definitely needs someone that proof reads it…}}
= Linux kernel vanilla repositories for Fedora Linux =


= kernel-vanilla packages for Fedora =
The kernel vanilla repositories allow you to quickly, comfortably, and cleanly install the latest upstream Linux kernel versions on Fedora Linux. [https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/ Six 'coprs' offer various ready-to-use kernel packages] built from upstream Linux series like ‘mainline’ and ‘stable’; the provided RPMs are ideal for both quick tests and regular day-to-day use.


== Overview ==
To install the latest kernel version deemed for end users, follow the instructions in the next section. For various other use cases, head over to the second section below to check which of the six coprs provides the Linux kernels you want; then enable the selected copr and install its latest kernel as explained in the third section. When you later want to remove the kernel vanilla repositories and all packages retrieved from them, consult the fourth section.


This page contains information about a [http://repos.fedorapeople.org/repos/thl/ set of package repositories] on fedorapeople.org that contain RPMs of Linux vanilla kernels built for Fedora. Vanilla in this scope means "unmodified", hence these packages do not contain any of those enhancements to the Linux source the Fedora developers integrate into the Linux kernel packages that Fedora normally uses.  
Note, the instructions in those sections are meant for users of Fedora variants like Workstation, Server, or KDE Plasma Desktop. Fedora Atomic Desktops like Silverblue or Kinoite need different commands described in a fifth section below.
Currently there is only one repository:


* [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-mainline/fedora-18/ kernel-vanilla-mainline for F18] ([http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/ repo file]) -- Latest Linux mainline kernel
== Install the latest Linux version meant for end users ==


The plan is also to provice these
To install the latest Linux kernel meant for regular end users run the following commands:


* kernel-vanilla-mainline for F17 -- latest mainline development kernel (aka latest 3.x snapshot)
<pre>
* kernel-vanilla-stable for F17 and F18 -- latest Linux stable series kernel (aka latest 3.x.y kernel)
sudo dnf -y copr enable @kernel-vanilla/stable
* kernel-vanilla-stable-testing for F17 and F18 -- latest Linux stable series kernel in testing (aka latest 3.x.y-rc kernel)
sudo dnf upgrade kernel
mokutil --sb-state
</pre>


To use those kernels download the repo file and put it in /etc/yum.repos.d/ and install the kernel you want with yum; the packages are signed with [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD7927A2FCC9DBCAB this key].  
The first two commands enable the ‘stable’ copr, which then is used via DNF to install the latest mainline kernel (say 6.1) or the latest version from a stable series derived from it (e.g. 6.1.1, 6.1.2, …). The third command will tell you if UEFI Secure Boot is active on your system. If that's the case you have to either disable it in your system's BIOS Setup or through a process initiated through <code>mokutil --disable-validation</code>; that's required, as your firmware will otherwise reject booting kernels installed from these repositories.


Please note a few important things:
== Linux kernels offered in the six kernel vanilla coprs ==


* none of the developers that maintain the Fedora kernel is involved in this effort
The kernel vanilla repositories for Fedora Linux provide six @kernel-vanilla coprs to serve different use-cases. Use the following table to decide which of them you want to use: ‘[https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/fedora/ fedora]’, ‘[https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/stable/ stable]’, ‘[https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/stable-rc/ stable-rc]’, ‘[https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/mainline-wo-mergew/ mainline-wo-mergew]’, ‘[https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/mainline/ mainline]’, or ‘[https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/next/ next]’.
* most systems work better and are run in a more secure manner with the official Fedora kernels (that's the long story short)
* the usage instructions are brief on purpose; if you don't understand them, then you likely should not use these packages


For more information see the FAQ.
{| class="wikitable"
!style="width: 17%;"|@kernel-vanilla copr
!style="width: 30%;"|provides
!style="width: 13%;"|example version sequence
!style="width: 40%;"|target users
|- style="vertical-align:top;"
| '''fedora'''
| The latest kernel version from the stable series the latest Fedora Linux release currently uses.
| …, 6.0.18,<br>6.0.19,<br>6.1.5,<br>6.1.6, …
| This is mainly meant for users that want to check if a bug that happens with Fedora's kernel also occurs with the latest upstream version from the same kernel series.
|- style="vertical-align:top;"
| '''stable'''
| The latest kernel version meant for regular end users; usually this is the newest version from the latest stable series, occasionally the latest mainline release.
| …, 6.0.15,<br>6.1,<br>6.1.1,<br>6.1.2, …
| Anyone who wants the latest and greatest kernel.
|- style="vertical-align:top;"
| '''stable-rc'''
| Pre-releases of the next release from the latest stable series.
| …, 6.0.15-rc1,<br>6.0.15,<br>6.1,<br>6.1.1-rc1,<br>6.1.1, …
| Anyone who wants to help testing Linux kernels from the latest stable series about to be released.
|- style="vertical-align:top;"
| '''mainline-wo-mergew'''
| The latest mainline kernel, either built from a pre-release (aka "rc kernel") or a Git snapshot of the day – albeit the latter only after -rc1 was released.
| …, 6.1-rc8-20221211,<br>6.1,<br>6.1.1-rc1,<br>6.1.1,<br>6.2-rc1,<br>6.2-rc1-20221226, …
| Anyone who wants to run a kernel built from the latest Linux codebase, except when mainline is in a 'merge window' – that is the phase right after a new mainline release (say 6.1) when the bulk of changes (including all riskier ones!) are merged for the next mainline version; this phase ends after two weeks with the publication of the next mainline kernel's first pre-release (e.g. 6.2-rc1).
|- style="vertical-align:top;"
| '''mainline'''
| The latest mainline kernel build from a Git snapshot of the day.
| …, 6.1-rc8-20221211,<br>6.1,<br>6.2-rc0-20221213,<br>6.2-rc0-20221214, …
| Anyone who wants to run kernels built from the latest Linux codebase.
|- style="vertical-align:top;"
| '''next'''
| Linux-next kernels.
| …, 6.1-0.0.next.20221209,<br>6.2-0.0.next.20221212, <br>6.2-0.0.next.20221213, …
| Anyone who wants to run linux-next or test if the changes slated for inclusion in the next mainline cycle fix a problem.
|}


== FAQ ==
'''Note''', only the coprs ‘fedora’ and ‘next’ are stand-alone; the other four each include coprs mentioned earlier in the table as a runtime dependency. Users of the ‘stable-rc’ copr thus will receive packages from the ‘stable’ or ‘fedora’ coprs when the latter contain kernels which package managers like DNF will considers newer. That way users of stable-rc copr won't be stuck on a -rc release with known problems fixed between the -rc and the final release; users of the 'mainline' repo will also receive daily snapshots from 'mainline-wo-mergew' repo once the merge window ended. The 'example version sequence' column takes these effects into account.


=== For users ===
Another note relevant for users of Fedora versions in development, e.g rawhide and beta releases: be aware that these coprs will not provide kernel versions older than the one the particular Fedora release uses by default, as doing so could lead to problems. Rawhide for example regularly uses the latest mainline snapshots; that’s why rawhide users that have one of these repos enabled will receive vanilla mainline snapshots as well, even if they chose the ‘stable’ or ‘mainline-wo-mergew’ repos. Users of Fedora pre-releases (e.g. beta versions) might see similar effects, but once the Fedora version gets closer to its release things will start to work as advertised.


==== Who is behind this effort? Can we trust the people behind it? ====
== How to install a kernel from the vanilla repositories ==


Right now the kernel-vanilla repositories are maintained by [[user:thl|Thorsten Leemhuis (aka "knurd")]] only. Mybe a few other people join to help over time, that's why this text is written as if a team is keeping care of the repositories.
First enable the kernel vanilla copr you want to use – for example the one shipping a kernel built from the latest mainline code:


You have to decide yourself if you can trust the packages from these repositories. If it is any help: Some of those that use or contribute to Fedora since a while will know that Thorsten has quite a history of Fedora contributions, even if he was not that much active in the past two years. You can assume he has no interest in ruin his reputation quickly by providing crap in these repositories. On the other hand you should know that Thorsten started these repositories to learn more about the kernel and kernel development; so expect he'll make some mistakes along the way. And be reminded that using vanilla kernels has some known downsides and risks (see below).
<pre>
sudo dnf -y copr enable @kernel-vanilla/mainline
</pre>


==== What's the goal? ====
Now update your system to install the latest package from the copr:


The main ideas is to help upstream development, which in the end will be of benefit for Fedora as well. With the packages from the mainline repositories it for example is quite easy to test kernels that are still under development and report bugs early. The kernels from the stable repositories on the other hand make it easy to check if a bug that happens with a kernel from Fedora is specific to it or also present in the newest vanilla kernel; if that is the case users can directly work with upstream on working out solutions for the problem and don't have to go through the sometimes overworked and quite busy developers that maintain the Linux kernel packages in Fedora.
<pre>
sudo dnf upgrade kernel kernel-devel
</pre>


==== Are the kernels from the kernel-vanilla repositories as good as those Fedora provides? ====
If you’re on a x86-64 (aka AMD64) system execute the following command as well:


No. There are several reasons for why not; the most important ones:
<pre>
mokutil --sb-state
</pre>


* the developers that take care of the kernel package in Fedora are far more experienced in packaging kernels and kernel development than those that take care of the kernel-vanilla repositories
If it tells you ‘SecureBoot enabled’ you will have to turn it off either in your BIOS Setup or through a process initiated with <code>sudo mokutil --disable-validation</code>. That sadly is needed, as your system otherwise will reject booting any kernels from these repositories: it's technically impossible to sign the kernels in copr with a key typical x86-64 systems will trust.
* the kernels that get used in Fedora or released as proper update get a lot of testing; the kernels from the kernel-vanilla repositories get nearly no testing
* some of the kernel-vanilla repositories contain kernels that are still under heavy development and sometimes are known to have serious bugs
* the official Fedora kernels sometimes contain changes that fix security problems or other crucial bugs before they get upstream


But the non-development kernels found in the kernel-vanilla repositories should work fine for a lot of situations and should normally be as good as a self-compiled kernel.
Once you booted your vanilla kernel you have two options:


==== Are the kernels safe to use? ====
(1) In case you want to use the chosen copr regularly, be aware that for frequently updated kernel vanilla coprs like mainline there is quite a risk that DNF misses the latest kernels and installs obsolete ones. To prevent that, tell dnf to check the kernel vanilla repositories more often than usual with a command like this one:


Depends on your definition of "safe".  
<pre>
sudo sed -i 's!baseurl=https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/\(mainline\|stable-rc\|next\).*!&\nmetadata_expire=1h!g; s!baseurl=https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/\(stable\|fedora\)/.*!&\nmetadata_expire=3h!g;' /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_kernel-vanilla:*.repo
</pre>


The Linux kernel is a complex piece of software which contains bugs. Those lead to data loss sometimes; in very rare situations they can even lead to hardware defects. Those bugs might only show up under specific circumstances -- for example when a specific mix of hardware is used with a specific kernel version that was built with a specific configuration. It might be unlikely that such a bug is triggered by one of the non-development kernels from the kernel-vanilla repositories, but it's definitely possible. Self compiled kernels bear the same risk; chances of hitting serious bugs are lower for kernels that have undergone widespread testing already.
(2) In case you installed a vanilla kernel just for a quick test, consider removing the just configured copr immediately, as explained in the next section. It also explains how to later uninstall packages installed from the kernel vanilla coprs, which is needed to ensure you retrieve newly released kernels from Fedora again.


In other words: The kernels from the kernel-vanilla repositories will work just fine for most people. But use them on your own risk and have backups handy, as there is a small risk those kernels might damage your data or your system.
== How to remove the kernel vanilla repositories and uninstall kernels installed from them ==


==== Should everything work with those kernels that works with the official Fedora kernels? ====
Disable any kernel vanilla copr you enabled:


No. Vanilla kernels are not that different from the kernels Fedora provides, but the latter include a few enhancements. Each was added for a good reason to make Fedora better, hence these improvements are missing when you use the vanilla Linux kernels.
<pre>
dnf copr list | grep 'group_kernel-vanilla' | xargs -r sudo dnf copr remove
</pre>


When this text was written Fedora for example included utrace in their Linux kernels to support userspace tracing with systemtap; hence that won't work with the kernels from the kernel-vanilla repositories. The kernels from Fedora sometimes include fresher drivers which some systems will require to work properly. And sometimes there are inter-dependencies between drivers in kernel and userland. The nouveau driver for graphics hardware from Nvidia was one such driver, as it had no stable API yet when this text was written; that's why the DRM/KMS driver in the kernel was marked as "staging" back then. The Mesa 3D or X.org drivers included in a particular Fedora release therefore might depend on the exact nouveau DRM/KMS driver which is part of the kernels Fedora ships for this release; thus the nouveau drivers for Mesa 3D and X.org that are part of a certain Fedora release might not work properly with kernels found in the kernel-vanilla repositories, as the latter might contain an older or newer nouveau DRM/KMS driver which are incompatible.
Now downgrade the kernel and a few related packages to the latest versions Fedora provides:


The non-development kernels found in the kernel-vanilla repositories therefore should work on a lot of systems, but on some systems they will be worse than the kernels Fedora provides.
<pre>
sudo dnf --refresh distrosync bpftool 'kernel*' 'libperf*' perf python3-perf rtla rv
</pre>


==== Where to report bugs ====
It's not strictly required, but highly recommended to boot into the latest official Fedora kernel now. To do so, restart and choose the top-most kernel from the boot menu that does not have 'vanilla' in the name.


If the Linux kernels in the packages from these repositories show any bugs please report them upstream to the Linux kernel developers, just as you would after installing a Linux kernel yourself with the sources available at [http://kernel.org kernel.org]; that way all the bug reports go to the place where the people hang out that know how to fix them.
Now remove all kernels installed from the kernel vanilla coprs:


In case there are bugs in the packaging sent a mail to [[user:thl|Thorsten Leemhuis (aka "knurd")]].
<pre>
rpm -qa 'kernel' 'kernel*core*' 'kernel*modules*' 'kernel*devel*' | grep '.vanilla' | xargs -r sudo dnf remove
</pre>


==== Will this repository also ship updates userland components like drivers or udev that match the kernels in the repositories? ====
If you disabled UEFI Secure Boot, you might want to turn it on again using the path you took to disable it, e.g. either through your BIOS Setup or a a process initiated with <code>sudo mokutil --enable-validation</code>.


No, as there should be no need to, as the interfaces between the kernel and userland software should never change in an incompatible way; Linus Torvalds makes this pretty clear every now and then.
From now on your system will behave like one that never had these repositories enabled or kernels installed from it.


That is the long story short. There are a lot of situations where the world is more complicated:
== Instructions for Fedora Atomic Desktops ==


* above mentioned rule does not apply to staging drivers, so situations might arise where the vanilla kernels are not usable for people that need staging drivers for their system. Apart from the nouveau drivers that shouldn't bother to many people; and time will tell how bad the situation is for nouveau.
'' '''Important note''': the following instructions only work as intended for the @kernel-vanilla coprs 'fedora' and 'next', as those are the only ones that are stand alone. The instructions most of the time will do the right thing on 'mainline-wo-mergew' copr as well; but with the @kernel-vanilla coprs 'stable', 'stable-rc', and 'mainline' they will often install an obsolete kernel and remain on it. That's because the latest versions suitable for users of those coprs in about 50 to 80 percent of the time is distributed through a higher level copr the repo files for those coprs enable as coprdep. The note under the table above explains this scheme in more detail. This approach works well with DNF, but [https://github.com/coreos/rpm-ostree/issues/4708 to our knowledge is unsupported by 'rpm-ostree overlay'], as it ignores the coprdep repos.''
* Fedora sometimes might contains software that depends on bits that are not upstream


And even with this rule sometimes a new mainline kernel versions brings changes that require updates userland software. Three examples:
Use the following commands to install the latest kernel from the 'mainline-wo-mergew' copr on Fedora Atomic Desktops like Silverblue or Kinoite:


* the version number jump from 2.6.39 to 3.0 confused some software
<pre>
* in rare cases fixing security problems was only possible my changing the interfaces in an incompatible way
copr="mainline-wo-mergew"
* sometimes nobody notices early enough that interfaces have changed
curl -s "https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/${copr}/repo/fedora-rawhide/group_kernel-vanilla-${copr}-fedora-rawhide.repo" | sudo tee "/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_kernel-vanilla:${copr}.repo"
sudo rpm-ostree override replace --experimental --from repo="copr:copr.fedorainfracloud.org:group_kernel-vanilla:${copr}" kernel kernel-core kernel-modules kernel-modules-core kernel-modules-extra
</pre>


It remains to be seen how often we hit such issues and how bad they are; how we deal with them will need to get discussed on a case by case basis. In some cases we might have to other solution then to add new versions of other software to the repositories. But the plan is to avoid this.
To later remove the kernel vanilla packages and the repository configuration, run the following commands:


==== Do you plan to provide packages for "linux-next" or "linux-rt" as well? ====
<pre>
sudo rpm-ostree override reset kernel kernel-core kernel-modules kernel-modules-core kernel-modules-extra
sudo rm "/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_kernel-vanilla"*
</pre>


For now: No. I know there is some interest in packages for them, but maintaining those will consume a lot of time regularly and we have not enough resources to do it properly right now.
== How vanilla kernels compare to Fedora’s ==


The CCMA people also build RT kernels already and it might be the best for everyone to not compete with them and simply ignore RT here.
Most of the time kernels from the kernel vanilla coprs 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 kernel used by Fedora Linux yet; other times it's the other way around, as Fedora sometimes includes fixes that upstream hasn't picked up yet. Those differences rarely matter much.


Packaging -next kernels might not be a good idea in general; it might be wise to leave -next to people that hand build kernels.
== Empty or apparently coprs are normal ==


But [[user:thl|get in contact]] if you think investing time in these makes sense.
Please be aware that at least one and up to three out of the six kernel vanilla coprs will always look empty or outdated when you check copr’s web interface or look straight at the package repositories. That is totally normal, as it will look like that when the most recent build suitable for users of that copr is found in one of the other copr included as a runtime dependency. See the note under above table for a more detailed explanation.


==== Do you plan to provide vanilla kernels for RHEL and derivatives like CentOS and SL? ====
== Linux kernel versions currently offered ==


Sounds like a good addition. But there are people more familiar with these dists that provide such packages already. It would mean  additional work, too; and we currently have no one that would regularly run such kernels. So for now we won't get our feet wet in that area. But if you want to step up and help, [[User:thl|get in contact]].
A '''[https://www.leemhuis.info/files/kernel-vanilla/repostatus.txt repostatus file shows what the repositories currently provide]'''. Alternatively, execute the following script to query the latest packages locally:


==== Do you plan to provide packages for longterm kernels ====
<pre>
dists=(38 39 40 rawhide)
dnf clean all > /dev/null
for repo in fedora stable{,-rc} mainline{-wo-mergew,} next; do
[[ ${repo} =~ (fedora|next) ]] && unset repostring
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
</pre>


Unlikely. Mail goal of the kernel-vanilla repositories is to help upstream kernel development; but longterm kernels are a dead end and quite far away from mainline development, so they would not fit that well. But it might make sense for RHEL and derivatives, if those will ever be supported by this effort.
== Developers behind the effort and point of contact  ==


==== What configuration do those kernels use? ====
The Linux kernel vanilla repositories for Fedora are maintained by [[user:thl|Thorsten Leemhuis (aka "knurd")]] since [https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/NNSLWMKQSGALKX7VGWATKWTGAOU6LZ5I/ late 2012]. The packages they provide are build using a RPM spec file that is nearly identical to the one used to build Fedora’s kernel. Note though that none of the maintainers of the the official Fedora Linux kernel are involved in the maintenance of these repositories.


Basically the same configuration the Fedora kernels use. Maybe a few staging drivers might get turned on to help their development, but apart from it the plan is to stick closely to what Fedora does.  
For any feedback or questions regarding the kernel vanilla repositories contact [[user:thl|Thorsten Leemhuis (aka "knurd")]].


==== Why don't you put these kernels in Fedoras main repositories ====
== What’s the goal of these repositories? And are these kernels as good as Fedora’s? ==


The current consensus is: That's not a good idea, as that would make them more "official" and people might simply use those packages without knowing what their downsides are.
These and many other questions are answered in the [[Kernel_Vanilla_Repositories-FAQ|FAQ about the Linux kernel vanilla repositories for Fedora Linux]].
 
That's the long story rough and short. And sure, there are reasons why having vanilla kernels in the main repositories make sense. Feel free to start a discussion on [https://admin.fedoraproject.org/mailman/listinfo/devel Fedoras devel mailing list], we'll watch and might jump in.
 
Putting the kernels in a well know 3rd party add-on repository for Fedora might make sense, but some of the problems would be similar; and there are others problems, as then users might ask to build add-on modules for those kernels, too. In other words: Would need discussion and careful evaluation.
 
==== Are those kernels really unpatched? ====
 
No, they contain a handful of very small changes that are needed for packaging.
 
From time to time the packages might use patches that are necessary temporary to make the kernel build or usable for most people; fixes like these will normally head upstream quickly and hence vanish from the vanilla packages again soon. And this normally should only happen with mainline development kernels, not with stable versions.
 
==== How up2date will those repositories be? ====
 
Time will tell, but we do the work in our spare time. Sometimes the day job and this strange thing called "real life" leave not much time to work on these kernels, so there will be a lag.
 
=== For contributors and developers ===
 
==== Can you please include this patch? ====
 
No. Get your patch merged upstream, then the change you are interested in will automatically show up in these packages (and in Fedora and other distributions, too)
 
==== Is there a Git tree somewhere? ====
 
[http://fedorapeople.org/cgit/thl/public_git/kernel.git/ Sure].
 
Let us know if we should do modifications to allow others to contribute to or benefit from this git tree better.
 
==== What Fedora versions will be supported ====
 
The plan is to support the most recent Fedora version for the stable and mainline repositories. The latter will also be provides for the distribution that is currently under development (rawhide on the first half of a devel cycle iteration or the alpha/beta/rcs in the second half)
 
==== Why are there no debug kernels and not even debuginfo packages ====
 
The space on repos.fedoraprople.org is limited, hence limiting the number of kernels we can provide. The debuginfo packages are also quite big, which makes them hard to handle. If there is interest, then may in the sort or medium timeframe solutions can be found to provide these packages.
 
==== Why don't you commit your changes to Fedora's kernel git repo on pkgs.fedoraproject.org? ====
 
Maybe that would make sense. But it bears the risk that a commit is done to a wrong branch and disturbs the work of the Fedora kernels maintainer. Further: Not all of those that contribute to Fedora can commit there. That's similar with the fedorapeople git repository, but the docs indicate others can be given access with the help of ACLs.
 
But whatever: Git is made for distributed development, so simply clone it and send pull requests if you have any additions.
 
==== Can I help ====
 
Of course. [[user:thl|Talk to Thorsten]]; best if you come with some ideas what you can and want to do.
 
==== Do you plan to work together with those that take care of the kernel packages in Fedora? ====
 
Definitely. But it remains to be seen how it looks like in practice.
 
==== Please stop providing alternative kernel packages, they take attention away from the kernels Fedora provide and thus harm Fedora! ====
 
That's a valid concern, but I think the benefits outweigh the downsides.
 
That again is the long story short. Just to get a little bit deeper into it: Similar arguments could be used to argue that Fedora should stop shipping patched kernels, as those take attention away from the upstream kernel. Up to a point such an argument is valid, too, but there are good reasons why Fedora patches its kernels.
 
Maybe in the long term Fedora can ship vanilla kernels as regular kernel. That would be best for all, but a goal that would take quite some effort and time to reach. Might be worth start a discussion on [https://admin.fedoraproject.org/mailman/listinfo/devel Fedoras devel mailing list] how to get closer to that goal.
 
==== Why did you drop the "-vanilla" postfix that normally gets added to the "name" macro when you build a vanilla kernel RPM locally? ====
 
I've thought about dropping or leaving it for a while, as both schemes have various benefits and downsides. In the end I went for dropping it due to reasons like this:
 
* nearly every other repository in Fedoraland that ships variants of a packages that are included in Fedora do not change the name
* the postfix breaks things like "fedpkg srpm" on the git checkout
* external solutions that heavily depend on the naming scheme fedora used (like the akmod/kmod stuff used in some external repositories) should just work
* yum would not recognize kernel packages with a "-vanilla" postfix as "installonly" and thus would perform a regular update for vanilla packages instead of installing them parallel to the current one
 
== Known issues and differences ==
 
The following sections will list differences to Fedora's proper kernel packages that might be relevant to users. It will also lists known problems specific to the packaging of the vanilla kernels.
 
Please note that these section will not lists any issues known in kernel version that are packaged, as it's best to maintain that information in a central place. So for a list of known bugs in the kernels packaged look at the [https://bugzilla.kernel.org/ the upstream bugtracker] and the [[http://news.gmane.org/gmane.linux.kernel|archives]] of mailing lists like the [http://www.tux.org/lkml/ LKML]].
 
=== General ===
 
None
 
=== F18 ===
 
None

Latest revision as of 06:16, 15 April 2024

Linux kernel vanilla repositories for Fedora Linux

The kernel vanilla repositories allow you to quickly, comfortably, and cleanly install the latest upstream Linux kernel versions on Fedora Linux. Six 'coprs' offer various ready-to-use kernel packages built from upstream Linux series like ‘mainline’ and ‘stable’; the provided RPMs are ideal for both quick tests and regular day-to-day use.

To install the latest kernel version deemed for end users, follow the instructions in the next section. For various other use cases, head over to the second section below to check which of the six coprs provides the Linux kernels you want; then enable the selected copr and install its latest kernel as explained in the third section. When you later want to remove the kernel vanilla repositories and all packages retrieved from them, consult the fourth section.

Note, the instructions in those sections are meant for users of Fedora variants like Workstation, Server, or KDE Plasma Desktop. Fedora Atomic Desktops like Silverblue or Kinoite need different commands described in a fifth section below.

Install the latest Linux version meant for end users

To install the latest Linux kernel meant for regular end users run the following commands:

sudo dnf -y copr enable @kernel-vanilla/stable
sudo dnf upgrade kernel
mokutil --sb-state

The first two commands enable the ‘stable’ copr, which then is used via DNF to install the latest mainline kernel (say 6.1) or the latest version from a stable series derived from it (e.g. 6.1.1, 6.1.2, …). The third command will tell you if UEFI Secure Boot is active on your system. If that's the case you have to either disable it in your system's BIOS Setup or through a process initiated through mokutil --disable-validation; that's required, as your firmware will otherwise reject booting kernels installed from these repositories.

Linux kernels offered in the six kernel vanilla coprs

The kernel vanilla repositories for Fedora Linux provide six @kernel-vanilla coprs to serve different use-cases. Use the following table to decide which of them you want to use: ‘fedora’, ‘stable’, ‘stable-rc’, ‘mainline-wo-mergew’, ‘mainline’, or ‘next’.

@kernel-vanilla copr provides example version sequence target users
fedora The latest kernel version from the stable series the latest Fedora Linux release currently uses. …, 6.0.18,
6.0.19,
6.1.5,
6.1.6, …
This is mainly meant for users that want to check if a bug that happens with Fedora's kernel also occurs with the latest upstream version from the same kernel series.
stable The latest kernel version meant for regular end users; usually this is the newest version from the latest stable series, occasionally the latest mainline release. …, 6.0.15,
6.1,
6.1.1,
6.1.2, …
Anyone who wants the latest and greatest kernel.
stable-rc Pre-releases of the next release from the latest stable series. …, 6.0.15-rc1,
6.0.15,
6.1,
6.1.1-rc1,
6.1.1, …
Anyone who wants to help testing Linux kernels from the latest stable series about to be released.
mainline-wo-mergew The latest mainline kernel, either built from a pre-release (aka "rc kernel") or a Git snapshot of the day – albeit the latter only after -rc1 was released. …, 6.1-rc8-20221211,
6.1,
6.1.1-rc1,
6.1.1,
6.2-rc1,
6.2-rc1-20221226, …
Anyone who wants to run a kernel built from the latest Linux codebase, except when mainline is in a 'merge window' – that is the phase right after a new mainline release (say 6.1) when the bulk of changes (including all riskier ones!) are merged for the next mainline version; this phase ends after two weeks with the publication of the next mainline kernel's first pre-release (e.g. 6.2-rc1).
mainline The latest mainline kernel build from a Git snapshot of the day. …, 6.1-rc8-20221211,
6.1,
6.2-rc0-20221213,
6.2-rc0-20221214, …
Anyone who wants to run kernels built from the latest Linux codebase.
next Linux-next kernels. …, 6.1-0.0.next.20221209,
6.2-0.0.next.20221212,
6.2-0.0.next.20221213, …
Anyone who wants to run linux-next or test if the changes slated for inclusion in the next mainline cycle fix a problem.

Note, only the coprs ‘fedora’ and ‘next’ are stand-alone; the other four each include coprs mentioned earlier in the table as a runtime dependency. Users of the ‘stable-rc’ copr thus will receive packages from the ‘stable’ or ‘fedora’ coprs when the latter contain kernels which package managers like DNF will considers newer. That way users of stable-rc copr won't be stuck on a -rc release with known problems fixed between the -rc and the final release; users of the 'mainline' repo will also receive daily snapshots from 'mainline-wo-mergew' repo once the merge window ended. The 'example version sequence' column takes these effects into account.

Another note relevant for users of Fedora versions in development, e.g rawhide and beta releases: be aware that these coprs will not provide kernel versions older than the one the particular Fedora release uses by default, as doing so could lead to problems. Rawhide for example regularly uses the latest mainline snapshots; that’s why rawhide users that have one of these repos enabled will receive vanilla mainline snapshots as well, even if they chose the ‘stable’ or ‘mainline-wo-mergew’ repos. Users of Fedora pre-releases (e.g. beta versions) might see similar effects, but once the Fedora version gets closer to its release things will start to work as advertised.

How to install a kernel from the vanilla repositories

First enable the kernel vanilla copr you want to use – for example the one shipping a kernel built from the latest mainline code:

sudo dnf -y copr enable @kernel-vanilla/mainline

Now update your system to install the latest package from the copr:

sudo dnf upgrade kernel kernel-devel

If you’re on a x86-64 (aka AMD64) system execute the following command as well:

mokutil --sb-state

If it tells you ‘SecureBoot enabled’ you will have to turn it off either in your BIOS Setup or through a process initiated with sudo mokutil --disable-validation. That sadly is needed, as your system otherwise will reject booting any kernels from these repositories: it's technically impossible to sign the kernels in copr with a key typical x86-64 systems will trust.

Once you booted your vanilla kernel you have two options:

(1) In case you want to use the chosen copr regularly, be aware that for frequently updated kernel vanilla coprs like mainline there is quite a risk that DNF misses the latest kernels and installs obsolete ones. To prevent that, tell dnf to check the kernel vanilla repositories more often than usual with a command like this one:

sudo sed -i 's!baseurl=https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/\(mainline\|stable-rc\|next\).*!&\nmetadata_expire=1h!g; s!baseurl=https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/\(stable\|fedora\)/.*!&\nmetadata_expire=3h!g;' /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_kernel-vanilla:*.repo

(2) In case you installed a vanilla kernel just for a quick test, consider removing the just configured copr immediately, as explained in the next section. It also explains how to later uninstall packages installed from the kernel vanilla coprs, which is needed to ensure you retrieve newly released kernels from Fedora again.

How to remove the kernel vanilla repositories and uninstall kernels installed from them

Disable any kernel vanilla copr you enabled:

dnf copr list | grep 'group_kernel-vanilla' | xargs -r sudo dnf copr remove

Now downgrade the kernel and a few related packages to the latest versions Fedora provides:

sudo dnf --refresh distrosync bpftool 'kernel*' 'libperf*' perf python3-perf rtla rv

It's not strictly required, but highly recommended to boot into the latest official Fedora kernel now. To do so, restart and choose the top-most kernel from the boot menu that does not have 'vanilla' in the name.

Now remove all kernels installed from the kernel vanilla coprs:

rpm -qa 'kernel' 'kernel*core*' 'kernel*modules*' 'kernel*devel*' | grep '.vanilla' | xargs -r sudo dnf remove

If you disabled UEFI Secure Boot, you might want to turn it on again using the path you took to disable it, e.g. either through your BIOS Setup or a a process initiated with sudo mokutil --enable-validation.

From now on your system will behave like one that never had these repositories enabled or kernels installed from it.

Instructions for Fedora Atomic Desktops

Important note: the following instructions only work as intended for the @kernel-vanilla coprs 'fedora' and 'next', as those are the only ones that are stand alone. The instructions most of the time will do the right thing on 'mainline-wo-mergew' copr as well; but with the @kernel-vanilla coprs 'stable', 'stable-rc', and 'mainline' they will often install an obsolete kernel and remain on it. That's because the latest versions suitable for users of those coprs in about 50 to 80 percent of the time is distributed through a higher level copr the repo files for those coprs enable as coprdep. The note under the table above explains this scheme in more detail. This approach works well with DNF, but to our knowledge is unsupported by 'rpm-ostree overlay', as it ignores the coprdep repos.

Use the following commands to install the latest kernel from the 'mainline-wo-mergew' copr on Fedora Atomic Desktops like Silverblue or Kinoite:

copr="mainline-wo-mergew"
curl -s "https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/${copr}/repo/fedora-rawhide/group_kernel-vanilla-${copr}-fedora-rawhide.repo" | sudo tee "/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_kernel-vanilla:${copr}.repo"
sudo rpm-ostree override replace --experimental --from repo="copr:copr.fedorainfracloud.org:group_kernel-vanilla:${copr}" kernel kernel-core kernel-modules kernel-modules-core kernel-modules-extra

To later remove the kernel vanilla packages and the repository configuration, run the following commands:

sudo rpm-ostree override reset kernel kernel-core kernel-modules kernel-modules-core kernel-modules-extra 
sudo rm "/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_kernel-vanilla"*

How vanilla kernels compare to Fedora’s

Most of the time kernels from the kernel vanilla coprs 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 kernel used by Fedora Linux yet; other times it's the other way around, as Fedora sometimes includes fixes that upstream hasn't picked up yet. Those differences rarely matter much.

Empty or apparently coprs are normal

Please be aware that at least one and up to three out of the six kernel vanilla coprs will always look empty or outdated when you check copr’s web interface or look straight at the package repositories. That is totally normal, as it will look like that when the most recent build suitable for users of that copr is found in one of the other copr included as a runtime dependency. See the note under above table for a more detailed explanation.

Linux kernel versions currently offered

A repostatus file shows what the repositories currently provide. Alternatively, execute the following script to query the latest packages locally:

dists=(38 39 40 rawhide)
dnf clean all > /dev/null
for repo in fedora stable{,-rc} mainline{-wo-mergew,} next; do
	[[ ${repo} =~ (fedora|next) ]] && unset repostring
	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

Developers behind the effort and point of contact

The Linux kernel vanilla repositories for Fedora are maintained by Thorsten Leemhuis (aka "knurd") since late 2012. The packages they provide are build using a RPM spec file that is nearly identical to the one used to build Fedora’s kernel. Note though that none of the maintainers of the the official Fedora Linux kernel are involved in the maintenance of these repositories.

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

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.