From Fedora Project Wiki

(s/http/https/ in the curl commands)
(47 intermediate revisions by 4 users not shown)
Line 1: Line 1:
= Linux vanilla kernels for Fedora =  
= Package repositories with Linux vanilla kernel packages for Fedora =  


= Overview =
The [http://repos.fedorapeople.org/repos/thl/ Linux vanilla kernel repositories for Fedora] offer RPM packages containing vanilla builds of different Linux kernel version lines. These packages are meant for Fedora users that want to access the latest Linux kernels quickly and comfortably; either the latest mainline kernel, the latest stable kernel or a vanilla variant of the Linux kernel series a particular Fedora release uses.


This page contains information about a [http://repos.fedorapeople.org/repos/thl/ set of package repositories] which 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 the Fedora developers integrate into the Linux kernel packages that Fedora normally uses.
= How to use these repos =


Currently there are these repositories:
== How to use, the TLDR version ==
 
* [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-mainline/ kernel-vanilla-mainline for F20, F21 and rawhide]
* [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/ kernel-vanilla-stable for F20]
* [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable-testing/ kernel-vanilla-stable-testing for F20]
 
To install the kernels from these repositories download the repo definitions for [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-mainline/fedora-kernel-vanilla-mainline.repo kernel-vanilla-mainline], [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-kernel-vanilla-stable.repo kernel-vanilla-stable] or [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-kernel-vanilla-stable.repo kernel-vanilla-stable] and put it in /etc/yum.repos.d/. You can do this with commands like these:


Download the definitions for the Kernel vanilla repositories:
<pre>
<pre>
# for the mainline repo
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla-mainline/fedora-kernel-vanilla-mainline.repo | sudo tee /etc/yum.repos.d/fedora-kernel-vanilla-mainline.repo
 
# for the stable repo
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-kernel-vanilla-stable.repo | sudo tee /etc/yum.repos.d/fedora-kernel-vanilla-stable.repo
 
# for the stable-testing repo
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-kernel-vanilla-stable.repo | sudo tee /etc/yum.repos.d/fedora-kernel-vanilla-stable.repo
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable-testing/fedora-kernel-vanilla-stable-testing.repo | sudo tee /etc/yum.repos.d/fedora-kernel-vanilla-stable-testing.repo  
</pre>
</pre>


To list the available packages use a command like this:
Run this to install the latest mainline (aka pre-release) kernel:
<pre>
<pre>
yum --disablerepo=* --enablerepo='fedora-kernel-vanilla-mainline' list available
sudo dnf --enablerepo=kernel-vanilla-mainline update
</pre>
</pre>


To install the latest kernel from the repo use a command like this:
Run this if you want the latest stable kernel instead:
<pre>
<pre>
sudo yum --disablerepo=* --enablerepo='fedora-kernel-vanilla-mainline' install kernel
sudo dnf --enablerepo=kernel-vanilla-stable update
</pre>
</pre>


When you install a kernel from the repo for the first time yum will ask you if you trust the [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD7927A2FCC9DBCAB the public key] that is used to verify the signature of the packages from the kernel vanilla repositories. It will look like this:
Reboot. That's it – at least often, as sometimes additional steps are necessary:
<pre>
Retrieving key from http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/RPM-GPG-KEY-fedora-kernel-vanilla
Importing GPG key 0xCC9DBCAB:
Userid    : "Thorsten Leemhuis (key for signing vanilla kernel pkgs for fedora) <fedora@leemhuis.info>"
Fingerprint: e5e8 d53e e5af be95 633d 690f d792 7a2f cc9d bcab
From      : http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/RPM-GPG-KEY-fedora-kernel-vanilla
Is this ok [y/N]:  
</pre>


Yum will proceed once you acknowledge this.  
* If UEFI Secure Boot is active on your system (which is the case on most modern systems), you'll have to disable it in your BIOS Setup or via <code>mokutil --disable-validation</code>. This is required to run kernels from these repositories, as they are not signed with a key typical systems will trust. If you don't known if UEFI Secure Boot is active on your system you might want to run <code>mokutil --sb-state</code> to find out.  


You are advised to add "kernel-devel" to above 'yum install' call, because that way you get the package that contains the files needed to compile kernel modules for the kernel you are installing; installing them later might not be possible, as the package you need might get removed when the repositories get updated the next time.
* The new kernel that above commands install will normally get started by default. If that's not the case there is likely something fishy with your boot configuration. For example, if you start Fedora using a boot manger from a different Linux distribution installed on your system you'll have to boot into the latter and update its boot loader configuration to make it detect the newly installed kernel. In Ubuntu you for example do that by running <code>update-grub</code>.  


Note that the kernel-vanilla-stable-testing repo is meant to be used in addition to kernel-vanilla-stable, so when you enable the former you should enable the latter as well; this will happen automatically if you rely on the commands mentioned above.
* The "dnf update"-command doesn't offer anything to install? Then the kernel package version in the Fedora release you use is higher than the version offered in the kernel-vanilla repository you chose to use. In that case the kernel vanilla repositories are lagging behind (its maintainers sometimes are on holiday, too!), hence it might be the best to stick to the kernel your have.


'''Important notes'''
You just want to use kernels from the kernel vanilla repositories for a short test? In that case once you finished your tests boot into the stock Fedora kernel again. Then uninstall all packages from these repos with the command <code>sudo dnf remove $(rpm -qa 'kernel*' | grep '.vanilla' )</code>.


Please note:
If you would like to permanently use kernels from these repos you might want to run one of these commands, depending on the type of kernels you want:


* none of the developers that maintain the Fedora kernel is involved in this effort
<pre>
* most systems work better and are run in a more secure manner with the official Fedora kernels
sudo dnf config-manager --set-enabled kernel-vanilla-mainline
* if you don't know what above command do then you likely should not use these packages
sudo dnf config-manager --set-enabled kernel-vanilla-stable
</pre>


More details on this can be found in the FAQ.
That way DNF will automatically install the latest packages from the particular repository when it updates your system the next time.


= FAQ =
Note: This TLDR-instructions focused on the two main repositories: 'mainline' and 'stable'. There are two more (called 'mainline-wo-mergew' and 'fedora') for other use cases described below.


== For users ==
A few common questions about these repos are answered in the [[Kernel_Vanilla_Repositories-FAQ|FAQ]].


=== Who is behind this effort?  ===
== How to use, the verbose version ==


Right now the Linux kernel vanilla repositories for Fedora are maintained by [[user:thl|Thorsten Leemhuis (aka "knurd")]] only. Maybe over time people join to help, that's why this text is written as if a team is keeping care of the repositories.
=== Configure the repositories ===


=== Can we trust the people behind it? ===
First download the repository definitions for DNF:


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 few 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 dig deeper into 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>
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo
</pre>


=== What's the goal? ===
This will install a repo file with following repos:


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 upstream, so they get fixed before a certain kernel version get released and later shipped as update to Fedora.  
{| class="wikitable"
!style="width: 15%;"|repository
!style="width: 35%;"|description
!style="width: 30%;"|target users
!style="width: 15%;"|example versions
|- style="vertical-align:top;"
| kernel-vanilla-mainline
| a mainline kernel, which IOW is a pre-release or git-snapshot from Linux's main development branch
| those who want the latest mainline Linux
| 4.3-rc7, 4.3-rc6-git2, 4.4, 4.5-rc0-git1, 4.5-rc1, 4.5-rc1-git2
|- style="vertical-align:top;"
| kernel-vanilla-mainline-wo-mergew
| similar to the kernel-vanilla-mainline repo, except during the merge window, when it will contain the latest released mainline kernel or a stable kernel based on it
| those who want the latest mainline kernel, but want to avoid development versions from the merge window – that the phase in the development cycle when the bulk of changes get merged for a new kernel version, which ends with the first pre-release, like 4.5-rc1
| 4.3-rc7, 4.3-rc6-git2, 4.4, 4.4.1, 4.5-rc1, 4.5-rc1-git2
|- style="vertical-align:top;"
| kernel-vanilla-stable
| the latest stable kernel according to kernel.org; as thus it won't have mainline releases like 4.4 and only start with 4.4.1
| those who want the latest Linux stable kernel
| 4.3.12, 4.3.13, 4.4.1, 4.4.2, 4.4.3
|- style="vertical-align:top;"
| kernel-vanilla-fedora
| contains a vanilla build of the latest kernel which Fedora currently ships or has in its update queue; most of the time this repository will contain the same kernels as kernel-vanilla-stable, except for times when Fedora hasn't yet jumped to the latest version line released from the mainline series.
| those who want to check if a vanilla kernel shows the same bug or behaviour as the Fedora kernel
| 4.3.19, 4.3.20, 4.4.5, 4.4.6
|}


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 from the mainline or the stable series; 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.
Decide yourself which of those you want to use. The following examples assume you want to use the <code>
kernel-vanilla-mainline</code> repository, hence if you want to use another repository you'll need to adjust the commands accordingly.


=== Are the kernels from the kernel-vanilla repositories as good as those Fedora provides? ===
=== Install a kernel from the repository ===


No. There are several reasons for why not; the most important ones:
Run this command to install the latest kernel from the kernel vanilla mainline repo:
<pre>
sudo dnf --enablerepo=kernel-vanilla-mainline update
</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
Alternatively you can permanently enable that repository to make DNF automatically install new kernel packages when updating the system:
* 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; they are only started in virtual machine and published if they boot.
* the official Fedora kernels sometimes contain changes that fix security problems or other crucial bugs before they get merged upstream


In addition:
<pre>
sudo dnf config-manager --set-enabled kernel-vanilla-mainline
sudo dnf update
</pre>


* the mainline repository contain kernels that are still under heavy development and hence sometimes have serious bugs.  
When you install a kernel from the repository for the first time DNF will ask you if you trust the [https://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD7927A2FCC9DBCAB public key] that is used to verify the signature of the packages from the kernel vanilla repositories. It will look like this:
<pre>
Retrieving key from https://repos.fedorapeople.org/repos/thl/RPM-GPG-KEY-knurd-kernel-vanilla
Importing GPG key 0x863625FA:
Userid    : "Thorsten Leemhuis (Key for signing vanilla kernel rpms) <fedora@leemhuis.info>"
Fingerprint: 7C71 B4C9 BF71 7876 635F 3205 4534 BEED 8636 25FA
From      : https://repos.fedorapeople.org/repos/thl/RPM-GPG-KEY-knurd-kernel-vanilla
Is this ok [y/N]:
</pre>


But in the end using the kernels from the kernel-vanilla repositories should not be any more dangerous than compiling and installing a kernel from source yourself.
Dnf will proceed once you acknowledge this.  


=== Thorsten, do you use the vanilla kernels yourself? ===
= Important notes =


Yes, I normally use one of the x86-64 vanilla kernels from the mainline repo, but I don't boot into each of them .
Please be aware that


=== Are the kernels safe to use? ===
* none of the developers that maintain the Fedora kernel is involved in the maintenance of the Fedora kernel vanilla repositories
* most systems work better and run in a more secure manner with the official Fedora kernels
* if you don't understand what above Dnf commands do then you likely should not use these repositories or its packages


Depends on your definition of 'safe'.
= More details about the kernel vanilla repos =


The Linux kernel is a complex piece of software which contains bugs. Those bugs lead to data loss sometimes; in very rare situations they can even damage hardware. 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 exactly the same risk; chances of hitting serious bugs are lower for kernels that have undergone widespread testing already, as those found in the official Fedora repositories.
== What Linux kernel versions do the various branches currently contain? ==


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 you always should.
Look at [http://www.leemhuis.info/files/kernel-vanilla/repostatus.txt the file repostatus.txt] or execute the following script to query the latest status locally:


=== Will everything work with the vanilla kernels that works with the official Fedora kernels? ===
<pre>
 
releases="34 33 32"; \
No. Linux 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 Linux vanilla kernels.
branches="mainline mainline-wo-mergew stable fedora"; \
 
for branch in ${branches} ; do for release in ${releases} ; do
When this text was written in the spring of 2012 Fedora for example included utrace in their Linux kernels to support userspace tracing with systemtap; hence this feature didn't work with the kernels from the kernel-vanilla repositories, but should be these days, as systemtap these days uses a upstream solution for its work.
  queryresult=$(dnf repoquery --repofrompath=repo,http://repos.fedorapeople.org/repos/thl/kernel-vanilla-${branch}/fedora-${release}/x86_64/ --disablerepo=* --enablerepo=repo --available --latest-limit=1 -q kernel 2>/dev/null)
 
  echo "${branch} ${release} ${queryresult:-not_available}"  
Another example: The kernels from Fedora sometimes include fresher drivers which some systems will require to work properly.
done; done | column -t | sed 's!kernel-0:!!; s!.x86_64!!;'
 
</pre>
Furthermore, 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 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 those might contain an incompatible nouveau DRM/KMS driver because it they are older or newer than the one part of the official Fedora kernel.
 
The non-development kernels found in the kernel-vanilla repositories therefore should work on a lot of systems, but on some systems they will definitely be worse than the kernels Fedora provides.
 
=== Where to report bugs ===
 
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.
 
In case there are bugs in the packaging sent a mail to [[user:thl|Thorsten Leemhuis (aka "knurd")]].
 
=== How can I avoid switching back and forth between vanilla kernels and Fedora kernels ? ===
 
Add 'exclude=kernel' to the first section of these files in /etc/yum.repos.d/
 
fedora.repo
fedora-updates.repo
fedora-updates-testing.repo
 
=== Will this repository also ship updates userland components like drivers or udev that match the kernels in the repositories? ===
 
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 now and then.
 
That is the long story short. There are situations where the world is more complicated:
 
* 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.
* Fedora sometimes might contain 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:
 
* the version number jump from 2.6.39 to 3.0 confused some software
* in rare cases fixing security problems was only possible my changing the interfaces in an incompatible way
* sometimes nobody notices early enough that interfaces have changed
and reverting the change might break systems that already rely on the new behaviour.
 
It remains to be seen how often we hit such issues and how bad they are; how we deal with them will be decided 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 if possible.
 
=== Do you plan to provide packages for "linux-next" or "linux-rt" as well? ===
 
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.
 
Furthermore, the CCMA people already build RT kernels and it might be the best for everyone to not compete with them.
 
Packaging -next kernels might not be a good idea in general, as chances these kernels contain serious bugs are way bigger than in the mainline of stable series. Hence it might be wise to leave -next to people that build kernels themselves.
 
[[user:thl|Get in contact]] if you think investing time in these areas makes sense.
 
=== Do you plan to provide vanilla kernels for RHEL and derivatives like CentOS and SL? ===
 
Sounds like a good addition. But there are people more familiar with these distributions that provide such packages already. It would mean additional work for us, 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]].
 
=== Do you plan to provide packages for longterm kernels ===
 
Unlikely. Main 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.
 
=== What configuration do those kernels use? ===
 
The mainline kernels ofBasically 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.
 
=== Why don't you put these kernels in Fedoras main repositories ===
 
The current consensus in the Fedora project as far as we see is: That's not a good idea, as that would make the vanilla Linux kernels more 'official' and people might simply use those kernels without knowing what their downsides are.  
 
That's the long story rough and short. And sure, there are reasons why having vanilla kernels in the main repositories would 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. It would lead to more problems, as then users might ask to build add-on modules for those kernels, too.
 
The best approach would be to reduce the number of patches the Fedora kernel developers include for one reason or another down to zero. That would require changes not only in Fedora, but in the upstream workflow as well.
 
=== 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 pretty soon again. Furthermore, this normally should only happen with mainline development kernels, not with stable kernels.
 
=== How up2date will those repositories be? ===
 
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 the patch found at <URL>? ===
 
No. Get your patch merged upstream, then the change you are interested in will automatically show up in these packages. And even better: it will automatically get into 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 always support the most recent Fedora version in the stable and mainline repositories. The mainline and sometimes the stable repo will also be provides for the distribution that is currently under development (rawhide on the first half of Fedoras development cycle iteration or the alpha/beta/rcs in the second half).
== Who is behind this effort?  ==


=== Why are there no debug kernels and not even debuginfo packages ===
Right now the kernel vanilla repositories for Fedora are maintained by [[user:thl|Thorsten Leemhuis (aka "knurd")]] only. Maybe over time people join to help, that's why this text is written as if a team is keeping care of the repositories.


The space on repos.fedoraprople.org is limited, hence we need to limit the number of packages 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.
== Which architectures are supported  ==


=== Why don't you commit your changes to Fedora's kernel git repo on pkgs.fedoraproject.org? ===
Aarch64 (aka ARM64) and x86-64 (aka AMD64, IA32E, x64, x86_64).


That might 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.
== How can I uninstall all kernels from the kernel vanilla repositories ==
 
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 work together with the developers that maintain Fedora's kernel packages? ===
 
There is cooperation already. If you think more is needed in some area let us know.
 
=== Please stop providing alternative kernel packages, they take attention away from the kernel packages Fedora provide and thus harm Fedora! ===
 
That's a valid concern, but we think the benefits outweigh the downsides.
 
That again that is the long story short. Just to get a little bit deeper into it and show a different view on the matter at hand: Similar arguments could be used to argue that Fedora should stop shipping patched kernels, as they 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.
 
=== Why did you drop the '-vanilla' postfix that normally gets added to the 'name' macro when you build Fedora's kernel RPM without patches 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 in the name breaks some tool -- for example things like 'fedpkg srpm' on the git checkout
* external solutions that heavily depend on the naming scheme Fedora uses (like the akmod/kmod stuff used in some external repositories) would break with the -vanilla postfix in the name
* 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
 
=== What kernel versions do the repos currently contain? ===
 
See yourself with a small script like this:


Boot into a stock Fedora kernel and run
<pre>
<pre>
releases="20 21 22"; branches="mainline stable stable-testing"; \
sudo dnf remove $(rpm -qa 'kernel*' | grep '.vanilla' )
for branch in ${branches} ; do for release in ${releases} ; do
  if result=$(repoquery --repofrompath=repo,http://repos.fedorapeople.org/repos/thl/kernel-vanilla-${branch}/fedora-${release}/x86_64/ --disablerepo=* --enablerepo=repo --qf '%{evr}' -q kernel 2>/dev/null); then
    echo "${branch} ${release} ${result}"; else
    echo "${branch} ${release} unavailable"; fi
done; done | column -t
</pre>
</pre>
Dnf will then show what is about to get uninstalled; review that list carefully and make sure you still have a none vanilla kernel on your system, otherwise you loose the ability to boot your installation. Better abort if something looks fishy. 


= Known issues and differences =
== What is the goal of these repositories? Are these kernels as good as those Fedora provides? ==


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.
These and many other questions are [[Kernel_Vanilla_Repositories-FAQ|answered in the FAQ about the kernel vanilla repositories]].


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]].
= ToDo list =


== General ==
Spec file:
* maybe ship debuginfo packages, which is not done due to size constrains; maybe CONFIG_DEBUG_INFO_REDUCED can help? or something else?
* maybe enable some of the staging drivers Fedora avoids


No issues known.
Repo:
 
* create stable-rc repo
= ToDo list =
* automate builds fully to keep repos more up2date


* enable some of the staging drivers Fedora avoids (basically those a well known add-on repository for Fedora ships as add-on package)
MISC:
* automate buils more to keep repos more up2date
* switch to kernel-ark as base for mainline builds
* automate builds for stable-testing kernels

Revision as of 10:28, 27 April 2021

Package repositories with Linux vanilla kernel packages for Fedora

The Linux vanilla kernel repositories for Fedora offer RPM packages containing vanilla builds of different Linux kernel version lines. These packages are meant for Fedora users that want to access the latest Linux kernels quickly and comfortably; either the latest mainline kernel, the latest stable kernel or a vanilla variant of the Linux kernel series a particular Fedora release uses.

How to use these repos

How to use, the TLDR version

Download the definitions for the Kernel vanilla repositories: 

curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo

Run this to install the latest mainline (aka pre-release) kernel: 

sudo dnf --enablerepo=kernel-vanilla-mainline update

Run this if you want the latest stable kernel instead: 

sudo dnf --enablerepo=kernel-vanilla-stable update

Reboot. That's it – at least often, as sometimes additional steps are necessary:

  • If UEFI Secure Boot is active on your system (which is the case on most modern systems), you'll have to disable it in your BIOS Setup or via mokutil --disable-validation. This is required to run kernels from these repositories, as they are not signed with a key typical systems will trust. If you don't known if UEFI Secure Boot is active on your system you might want to run mokutil --sb-state to find out.
  • The new kernel that above commands install will normally get started by default. If that's not the case there is likely something fishy with your boot configuration. For example, if you start Fedora using a boot manger from a different Linux distribution installed on your system you'll have to boot into the latter and update its boot loader configuration to make it detect the newly installed kernel. In Ubuntu you for example do that by running update-grub.
  • The "dnf update"-command doesn't offer anything to install? Then the kernel package version in the Fedora release you use is higher than the version offered in the kernel-vanilla repository you chose to use. In that case the kernel vanilla repositories are lagging behind (its maintainers sometimes are on holiday, too!), hence it might be the best to stick to the kernel your have.

You just want to use kernels from the kernel vanilla repositories for a short test? In that case once you finished your tests boot into the stock Fedora kernel again. Then uninstall all packages from these repos with the command sudo dnf remove $(rpm -qa 'kernel*' | grep '.vanilla' ).

If you would like to permanently use kernels from these repos you might want to run one of these commands, depending on the type of kernels you want: 

sudo dnf config-manager --set-enabled kernel-vanilla-mainline
sudo dnf config-manager --set-enabled kernel-vanilla-stable

That way DNF will automatically install the latest packages from the particular repository when it updates your system the next time.

Note: This TLDR-instructions focused on the two main repositories: 'mainline' and 'stable'. There are two more (called 'mainline-wo-mergew' and 'fedora') for other use cases described below.

A few common questions about these repos are answered in the FAQ.

How to use, the verbose version

Configure the repositories

First download the repository definitions for DNF: 

curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo

This will install a repo file with following repos:

repository description target users example versions
kernel-vanilla-mainline a mainline kernel, which IOW is a pre-release or git-snapshot from Linux's main development branch those who want the latest mainline Linux 4.3-rc7, 4.3-rc6-git2, 4.4, 4.5-rc0-git1, 4.5-rc1, 4.5-rc1-git2
kernel-vanilla-mainline-wo-mergew similar to the kernel-vanilla-mainline repo, except during the merge window, when it will contain the latest released mainline kernel or a stable kernel based on it those who want the latest mainline kernel, but want to avoid development versions from the merge window – that the phase in the development cycle when the bulk of changes get merged for a new kernel version, which ends with the first pre-release, like 4.5-rc1 4.3-rc7, 4.3-rc6-git2, 4.4, 4.4.1, 4.5-rc1, 4.5-rc1-git2
kernel-vanilla-stable the latest stable kernel according to kernel.org; as thus it won't have mainline releases like 4.4 and only start with 4.4.1 those who want the latest Linux stable kernel 4.3.12, 4.3.13, 4.4.1, 4.4.2, 4.4.3
kernel-vanilla-fedora contains a vanilla build of the latest kernel which Fedora currently ships or has in its update queue; most of the time this repository will contain the same kernels as kernel-vanilla-stable, except for times when Fedora hasn't yet jumped to the latest version line released from the mainline series. those who want to check if a vanilla kernel shows the same bug or behaviour as the Fedora kernel 4.3.19, 4.3.20, 4.4.5, 4.4.6

Decide yourself which of those you want to use. The following examples assume you want to use the kernel-vanilla-mainline repository, hence if you want to use another repository you'll need to adjust the commands accordingly.

Install a kernel from the repository

Run this command to install the latest kernel from the kernel vanilla mainline repo: 

sudo dnf --enablerepo=kernel-vanilla-mainline update

Alternatively you can permanently enable that repository to make DNF automatically install new kernel packages when updating the system: 

sudo dnf config-manager --set-enabled kernel-vanilla-mainline
sudo dnf update

When you install a kernel from the repository for the first time DNF will ask you if you trust the public key that is used to verify the signature of the packages from the kernel vanilla repositories. It will look like this: 

Retrieving key from https://repos.fedorapeople.org/repos/thl/RPM-GPG-KEY-knurd-kernel-vanilla
Importing GPG key 0x863625FA:
 Userid     : "Thorsten Leemhuis (Key for signing vanilla kernel rpms) <fedora@leemhuis.info>"
 Fingerprint: 7C71 B4C9 BF71 7876 635F 3205 4534 BEED 8636 25FA
 From       : https://repos.fedorapeople.org/repos/thl/RPM-GPG-KEY-knurd-kernel-vanilla
Is this ok [y/N]:

Dnf will proceed once you acknowledge this.

Important notes

Please be aware that

  • none of the developers that maintain the Fedora kernel is involved in the maintenance of the Fedora kernel vanilla repositories
  • most systems work better and run in a more secure manner with the official Fedora kernels
  • if you don't understand what above Dnf commands do then you likely should not use these repositories or its packages

More details about the kernel vanilla repos

What Linux kernel versions do the various branches currently contain?

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

releases="34 33 32"; \
branches="mainline mainline-wo-mergew stable fedora"; \
for branch in ${branches} ; do for release in ${releases} ; do
  queryresult=$(dnf repoquery --repofrompath=repo,http://repos.fedorapeople.org/repos/thl/kernel-vanilla-${branch}/fedora-${release}/x86_64/ --disablerepo=* --enablerepo=repo --available --latest-limit=1 -q kernel 2>/dev/null)
  echo "${branch} ${release} ${queryresult:-not_available}" 
done; done | column -t | sed 's!kernel-0:!!; s!.x86_64!!;'

Who is behind this effort?

Right now the kernel vanilla repositories for Fedora are maintained by Thorsten Leemhuis (aka "knurd") only. Maybe over time people join to help, that's why this text is written as if a team is keeping care of the repositories.

Which architectures are supported

Aarch64 (aka ARM64) and x86-64 (aka AMD64, IA32E, x64, x86_64).

How can I uninstall all kernels from the kernel vanilla repositories

Boot into a stock Fedora kernel and run 

sudo dnf remove $(rpm -qa 'kernel*' | grep '.vanilla' )

Dnf will then show what is about to get uninstalled; review that list carefully and make sure you still have a none vanilla kernel on your system, otherwise you loose the ability to boot your installation. Better abort if something looks fishy.

What is the goal of these repositories? Are these kernels as good as those Fedora provides?

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

ToDo list

Spec file:

  • maybe ship debuginfo packages, which is not done due to size constrains; maybe CONFIG_DEBUG_INFO_REDUCED can help? or something else?
  • maybe enable some of the staging drivers Fedora avoids

Repo:

  • create stable-rc repo
  • automate builds fully to keep repos more up2date

MISC:

  • switch to kernel-ark as base for mainline builds
Retrieved from "https://fedoraproject.org/w/index.php?title=Kernel_Vanilla_Repositories&oldid=613646"