From Fedora Project Wiki

(create page)
 
No edit summary
(42 intermediate revisions by 4 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…}}
= Package repository with Linux vanilla kernels for Fedora =


= kernel-vanilla packages for Fedora =
This page contains information about a [http://repos.fedorapeople.org/repos/thl/ set of repositories] which contain RPM packages with Linux vanilla kernels built for Fedora. 'Vanilla' in this scope means 'unmodified'. In other words: the sources used to compile those kernels come straight from kernel.org and do not contain any of the enhancements which the official Fedora kernels contain.


== Overview ==
= How to use these repos =


This page contains information about a [http://repos.fedorapeople.org/repos/thl/ set of package repositories] on fedorapeople.org that contain RPMs of 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 kernel packages that Fedora normally contains.
== How to use, the quick (aka TLDR) verison ==
Currently there is only one repository:


* [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-16/ kernel-vanilla-stable for F16] ([http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/ repo file]) -- Latest kernel from the stable series (3.x.y)
Download the definitions for the Kernel vanilla repositories:
<pre>
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo
</pre>


There will be one more soon:  
Run this to get the latest development kernel:
<pre>
sudo dnf --enablerepo=kernel-vanilla-mainline update
</pre>


* kernel-vanilla-mainline for F16 -- latest mainline development kernel (aka 3.x-rc series)
You don't want to run a development kernel and want the latest stable kernel instead? Then run this:
<pre>
sudo dnf --enablerepo=kernel-vanilla-stable update
</pre>


There is the rough idea for more:  
Reboot. That's it – at least most of the time, as sometimes it's not that easy:


* kernel-vanilla-mainline for F17 -- latest mainline development kernel (aka 3.x-rc series)
* Is UEFI Secure Boot active on your system? Then you have to disable it in your BIOS Setup to run kernels from these repos, as they are not signed with a key that a default Secure Boot setup considers trusted.
* kernel-vanilla-stable-testing for F16 -- 3.x.y-rc kernels could go here; might also be a good place to put new releases from the mainline (3.x) or stable series (3.x.y) here for a short while before moving them to kernel-vanilla-stable


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].  
* Nothing gets installed by the "dnf update"-command? Then the version of the latest kernel package installed on your machine is higher than the version of the latest kernel packagers offered in the chosen kernel-vanilla repository.  


Please note a few important things:
* The newly installed kernel should get started by default. If that's not the case there is something fishy in your boot configuration. For example, if you start Fedora using a boot manger from a different distribution you'll have to boot into that one and update its boot loader configuration to start the newly installed kernel; in Ubuntu you do that by running <code>update-grub</code>.


* none of the developers that maintain the Fedora kernel is involved in this effort
Optionally run
* most systems work better and are run in a more secure manner with the official Fedora kernels
<pre>
* the usage instructions are brief on purpose; if you don't understand them, then you likely should not use these packages
sudo dnf config-manager --set-enabled kernel-vanilla-mainline
</pre>


For more information see the FAQ.
or


== FAQ ==
<pre>
sudo dnf config-manager --set-enabled kernel-vanilla-stable
</pre>


=== For users ===
if you want to enable one of those repos permanently. They are the two main repos this page is about. There are three more for special use cases. For details see below.


==== Who is behind this effort? Can we trust the people behind it? ====
== How to use, the verbose version ==


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


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 the vanilla kernels have some known downsides (see below)
First download the repository definitions for DNF:


==== What's the goal? ====
<pre>
curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo
</pre>


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 solutions for the problem and don't have to go through the overworked and quite busy developers that maintain the kernel packages in Fedora.
This will install a repo file with following repos:


==== Are the kernels from the kernel-vanilla repositories as good as those Fedora provides? ====
{| class="wikitable"
!style="vertical-align:top;"|repository
!description
!target users
!example versions
|- style="vertical-align:top;"
| kernel-vanilla-mainline
| the latest kernels from the Linux mainline series
| those who want the latest mainline kernel
| 4.4, 4.5-rc0-git1, 4.5-rc1, 4.5-rc1-git2
|- style="vertical-align:top;"
| kernel-vanilla-mainline-wo-mergew
| the latest kernels from the Linux mainline series, except during the merge window, when it might contain the latest stable kernel.
| those who want the latest mainline kernel, but want to avoid development versions from the merge window (like 4.5-rc0-git1) – that the phase in the development cycle when the bulk of changes get merged for a new kernel version
| 4.4, 4.4.1, 4.5-rc1, 4.5-rc1-git2
|- style="vertical-align:top;"
| kernel-vanilla-stable
| the latest non-development version from the mainline or stable kernel series
| those who want the latest Linux stable kernel
| 4.4, 4.4.1
|- style="vertical-align:top;"
| kernel-vanilla-stable-rc
| the latest non-development version from the mainline or stable kernel series, but also kernels from the stable series that are about to get released
| those who want to help testing new stable kernels
| 4.4, 4.4.1, 4.4.2-rc1
|- 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 major version
| those who want to check if a vanilla kernel shows the same bug or behavior as the Fedora kernel
| 4.4, 4.4.1
|}


No. There are several reasons for why not; the most important ones:
Chose which one of those you want to use. The following examples assume you want to use the <code>
kernel-vanilla-mainline</code> repository, hence adjust the commands if you want to use a different repository.


* 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
=== Install a kernel from the repository ===
* 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 before they get upstream


But the non-development kernels found in the kernel-vanilla repositories should work fine for a lot of situations and often be round about as good as a self-compiled kernel.
Run this command to install the latest mainline kernel from the kernel vanilla repos:
<pre>
sudo dnf --enablerepo=kernel-vanilla-mainline update
</pre>


==== Are the kernels safe to use? ====
Alternatively you can permanently enable that repository to make DNF automatically install new kernel packages when updating the system:


Depends on your definition of "safe".
<pre>
sudo dnf config-manager --set-enabled kernel-vanilla-mainline
sudo dnf update
</pre>


The Linux kernel is a complex piece of software which contains bugs. Those can lead to data loss or in very rare situations 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.
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 0xCC9DBCAB:
Userid    : "Thorsten Leemhuis (Key for signing vanilla kernel rpms) <fedora@leemhuis.info>"
Fingerprint: e5e8 d53e e5af be95 633d 690f d792 7a2f cc9d bcab
From      : https://repos.fedorapeople.org/repos/thl/RPM-GPG-KEY-knurd-kernel-vanilla
Is this ok [y/N]:
</pre>


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.
DNF will proceed once you acknowledge this.  


==== Should everything work with those kernels that works with the official Fedora kernels? ====
= Important notes =


No. Vanilla kernels are not that different from the kernels Fedora provides, but the latter include a few enhancements. Each of them is there for a good reason.
Please be aware that


When this text was written Fedora for example included utrace in their kernels to support userspace tracing with systemtap; 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 is one such driver, as it has no stable API yet; that's why the DRM/KMS driver in the kernel is marked as "staging". 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.
* none of the developers that maintain the Fedora kernel is involved in the maintenance of the kernel vanilla repos for Fedora
 
* most systems work better and are run in a more secure manner with the official Fedora kernels
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.
* if you don't know what above commands do then you likely should not use these repos or its packages
 
==== 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 every now and then.
 
That is the long story short. There are a lot of 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. Apart from the nouveau drivers that shouldn't bother to many people; and time will tell how bad the situation is for nouveau.
* 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:
 
* 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
 
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.
 
==== 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. But if you want to step up and help, [[user:thl|get in contact]].
 
==== Do you plan to provide vanilla kernels for RHEL and derivatives like CentOS and SL? ====
 
Sounds like a good addition. But it will result in 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]].
 
==== Do you plan to provide packages for longterm kernels ====
 
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.
 
==== What configuration do those kernels use? ====
 
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.
 
==== Why don't you put these kernels in Fedoras main repositories ====
 
I tend to think it'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.
 
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 few changes that are needed for packaging.
 
==== 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, too)
 
==== Is there a Git tree somewhere? ====
 
[http://fedorapeople.org/gitweb?p=thl/public_git/kernel.git;a=summary 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 ====
= More details about the kernel vanilla repos =


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. Hopefully in the short or medium timeframe solutions can be found to provide these packages.
== What kernel versions do the repos currently contain? ==


==== Why don't you commit your changes to Fedora's kernel git repo on pkgs.fedoraproject.org? ====
Look at [http://www.leemhuis.info/files/kernel-vanilla/repostatus.txt this file] or cut'n'paste these lines if you want to query the latest status yourself:


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.
<pre>
releases="25 24 23 22"; branches="mainline mainline-wo-mergew stable-rc 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!!;'
</pre>


But whatever: Git is made for distributed development and it's likely not a big deal where the git repo lives.
== Who is behind this effort?  ==


==== Can I help ====
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.


Of course. [[user:thl|Talk to Thorsten]]; best if you come with some ideas what you can and want to do.
== How can I uninstall all kernels from the kernel vanilla repositories ==


==== Do you plan to work together with those that take care of the kernel packages in Fedora? ====
Boot into a stock Fedora kernel and run
<pre>
sudo dnf remove $(rpm -qa 'kernel*' | grep '.vanilla.knurd' )
</pre>
DNF will then show what is about to get uninstalled; review that list carefully and better abort if something looks fishy. 


Definitely. But it remains to be seen how it looks like in practice.
== What is the goal of these repositories? Are these kernels as good as those Fedora provides? ==


==== Please stop providing alternative kernel packages, they take attention away from the kernels Fedora provide and thus harm Fedora! ====
These and other questions are [[Kernel_Vanilla_Repositories-FAQ|answered in the FAQ about the kernel vanilla repositories]].


That's a valid concern, but I think the benefits outweigh the downsides.
= Known issues and differences =


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.  
The following sections will list differences to Fedora's proper kernel packages that might be relevant to users. It will also list known problems specific to the packaging of the vanilla kernels.


Maybe in the long term Fedora can ship vanilla kernels as regular kernel. That would be best for all, but a goal that is would take quite some effort 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.
== General ==


==== Why did you drop the "-vanilla" postfix that normally gets added to the "name" macro when you build a vanilla kernel RPM locally? ====
* No issues known.


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:
= ToDo list =


* nearly every other repository in Fedoraland that ships variants of a packages that is included in Fedora does not change the name
* enable some of the staging drivers Fedora avoids (basically those a well known add-on repository for Fedora ships as add-on package)
* the postfix breaks things like "fedpkg srpm" on the git checkout
* automate builds more to keep repos more up2date
* external solutions that heavily depend on the naming scheme fedora used (like the kmod stuff used in some external repositories) should just work
* automate builds for stable-testing kernels
* 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

Revision as of 06:55, 7 April 2016

Package repository with Linux vanilla kernels for Fedora

This page contains information about a set of repositories which contain RPM packages with Linux vanilla kernels built for Fedora. 'Vanilla' in this scope means 'unmodified'. In other words: the sources used to compile those kernels come straight from kernel.org and do not contain any of the enhancements which the official Fedora kernels contain.

How to use these repos

How to use, the quick (aka TLDR) verison

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 get the latest development kernel:

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

You don't want to run a development kernel and want the latest stable kernel instead? Then run this:

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

Reboot. That's it – at least most of the time, as sometimes it's not that easy:

  • Is UEFI Secure Boot active on your system? Then you have to disable it in your BIOS Setup to run kernels from these repos, as they are not signed with a key that a default Secure Boot setup considers trusted.
  • Nothing gets installed by the "dnf update"-command? Then the version of the latest kernel package installed on your machine is higher than the version of the latest kernel packagers offered in the chosen kernel-vanilla repository.
  • The newly installed kernel should get started by default. If that's not the case there is something fishy in your boot configuration. For example, if you start Fedora using a boot manger from a different distribution you'll have to boot into that one and update its boot loader configuration to start the newly installed kernel; in Ubuntu you do that by running update-grub.

Optionally run

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

or

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

if you want to enable one of those repos permanently. They are the two main repos this page is about. There are three more for special use cases. For details see below.

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 the latest kernels from the Linux mainline series those who want the latest mainline kernel 4.4, 4.5-rc0-git1, 4.5-rc1, 4.5-rc1-git2
kernel-vanilla-mainline-wo-mergew the latest kernels from the Linux mainline series, except during the merge window, when it might contain the latest stable kernel. those who want the latest mainline kernel, but want to avoid development versions from the merge window (like 4.5-rc0-git1) – that the phase in the development cycle when the bulk of changes get merged for a new kernel version 4.4, 4.4.1, 4.5-rc1, 4.5-rc1-git2
kernel-vanilla-stable the latest non-development version from the mainline or stable kernel series those who want the latest Linux stable kernel 4.4, 4.4.1
kernel-vanilla-stable-rc the latest non-development version from the mainline or stable kernel series, but also kernels from the stable series that are about to get released those who want to help testing new stable kernels 4.4, 4.4.1, 4.4.2-rc1
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 major version those who want to check if a vanilla kernel shows the same bug or behavior as the Fedora kernel 4.4, 4.4.1

Chose which one of those you want to use. The following examples assume you want to use the kernel-vanilla-mainline repository, hence adjust the commands if you want to use a different repository.

Install a kernel from the repository

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

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 0xCC9DBCAB:
 Userid     : "Thorsten Leemhuis (Key for signing vanilla kernel rpms) <fedora@leemhuis.info>"
 Fingerprint: e5e8 d53e e5af be95 633d 690f d792 7a2f cc9d bcab
 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 kernel vanilla repos for Fedora
  • most systems work better and are run in a more secure manner with the official Fedora kernels
  • if you don't know what above commands do then you likely should not use these repos or its packages

More details about the kernel vanilla repos

What kernel versions do the repos currently contain?

Look at this file or cut'n'paste these lines if you want to query the latest status yourself:

releases="25 24 23 22"; branches="mainline mainline-wo-mergew stable-rc 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.

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.knurd' )

DNF will then show what is about to get uninstalled; review that list carefully and better abort if something looks fishy.

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

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

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 list known problems specific to the packaging of the vanilla kernels.

General

  • No issues known.

ToDo list

  • enable some of the staging drivers Fedora avoids (basically those a well known add-on repository for Fedora ships as add-on package)
  • automate builds more to keep repos more up2date
  • automate builds for stable-testing kernels