From Fedora Project Wiki

m
(a few small fixes and adjustments all over)
 
Line 5: Line 5:
 
== What's the goal of these repositories? ==
 
== What's the goal of these repositories? ==
  
The main ideas is to help upstream development, which in the end will benefit Fedora as well. With the packages from the mainline repositories it for example is quite easy to test kernels that are still under development. Then bugs can be found early and reported upstream, so they get fixed way before a new kernel version get released and shipped as a porper update in Fedora.  
+
The main ideas is to help upstream development, which in the end will benefit Fedora as well.
  
The kernels from the kernel-vanilla-fedora repositories on the other hand make it easy to check if a bug that happens with a Fedora kernel is specific to it or also present in a vanilla build. The kernels from the kernel-vanilla-stable repositories make it easy to check if a bug still happens with the latest stable 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 sometimes overworked and quite busy developers that maintain the Linux kernel packages in Fedora.
+
* With the packages from the kernel-vanilla-mainline repository it for example is quite easy to test kernels that are still under development. Bugs thus can be found early and reported and fixed upstream way before they enter a Linux kernel version shipped as a proper update in Fedora.
 +
* The kernels from the kernel-vanilla-fedora repository make it easy to check if a bug that happens with a Fedora kernel is present upstream or caused by the patches the Fedora developers apply.  
 +
* The kernels from the kernel-vanilla-stable repositories make it easy to check if a particular bug still happens with the latest stable kernel.  
 +
 
 +
In general, these kernels make it easier to directly interact with upstream developers. That way users don't have to go through the sometimes overworked and quite busy developers that maintain the Linux kernel packages in Fedora.
  
 
== Are the kernels from the kernel-vanilla repositories as good as those Fedora provides? ==
 
== Are the kernels from the kernel-vanilla repositories as good as those Fedora provides? ==
Line 13: Line 17:
 
No. There are several reasons for why not; the most important ones:
 
No. There are several reasons for why not; the most important ones:
  
* the developers that take care of the kernel package in Fedora are far more experienced in packaging kernels and kernel development itself than those that take care of the kernel-vanilla repositories
+
* the kernels that get used in Fedora or released as proper update get a lot of testing before getting shipped as proper update. The kernels from the kernel vanilla repositories get nearly no testing; they are only started in virtual machine and published as long as they boot there.
* the kernels that get used in Fedora or released as proper update get a lot of testing before getting shipped as proper update . The kernels from the kernel vanilla repositories get nearly no testing; they are only started in virtual machine and published as long as they boot there.
+
* the official Fedora kernels sometimes contain changes that fix security problems or other crucial bugs before the fix gets merged upstream.
* the official Fedora kernels sometimes contain changes that fix security problems or other crucial bugs before the fix gets merged upstream
+
* the developers that take care of the kernel package in Fedora are far more experienced developers than those that take care of the kernel-vanilla repositories.
  
In addition: It should be obvious that kernels from the mainline repository are typically still under heavy development and occasionally might have serious bugs that could lead to data loss. 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.
+
In addition, it should be obvious that kernels from the mainline repository are typically still under heavy development and occasionally might have serious bugs that in rare cases can even lead to data loss. But in the end using the kernels from the kernel-vanilla repositories should not be anymore dangerous than downloading a Linux version from kernel.org and compiling and installing it source yourself.
  
 
== Why so many repos? This looks stupid and over-engineered! ==
 
== Why so many repos? This looks stupid and over-engineered! ==
  
Yes, it looks over-engineered on the first sight, but allows us to serve users just what they want; and once you look closer you'll notice that most of the time those four repositories contain only two Linux kernel versions per Fedora release.  
+
Yes, it might look over-engineered on the first sight, but allows us to serve users with just what they want; and once you look closer you'll notice that most of the time those four repositories contain only two Linux kernel versions per Fedora release.  
  
[[File:Kernel.org-20180419.png|thumb|Kernel.org frontpage on 2018-04-09]] To explain this a bit more let's for example take a look April 9th, 2018. Back then
+
[[File:Kernel.org-20180419.png|thumb|Kernel.org frontpage on 2018-04-09]] To explain this a bit more lets for example take a look April 9th, 2018. Back then…
  
 
* Linux 4.16 was one week old and the first stable release 4.16.1 had just been released.  
 
* Linux 4.16 was one week old and the first stable release 4.16.1 had just been released.  
 
* Linux 4.17 had one week into development, thus Linux 4.17-rc1 was still one week away.
 
* Linux 4.17 had one week into development, thus Linux 4.17-rc1 was still one week away.
* Linux 4.15.x was still supported upstream and 4.15.16 had just been released
+
* Linux 4.15.x was still supported upstream and 4.15.16 had just been released.
  
At the same time
+
At the same time…
  
* Fedora 29 was Rawhide and uses a mainline snapshot (4.17-pre-rc1)
+
* Fedora 29 was Rawhide and contained a mainline snapshot (4.17-pre-rc1).
* Fedora 28 was in Beta and used 4.16.x
+
* Fedora 28 was in Beta and contained 4.16.x.
* Fedora 27 and 26 were the current releases and used a Kernel based on Linux 4.15.x
+
* Fedora 27 and 26 were the current releases and contained a Kernel based on Linux 4.15.x.
  
In this situation there were
+
In this particular point in time there were…
  
 
* users that want the latest mainline snapshots (4.17-pre-rc1)
 
* users that want the latest mainline snapshots (4.17-pre-rc1)
* users that normally want the latest mainline snapshots, but want to avoid them during the busy merge window when most of the changes are done. Thos back then thus wanted the latest stable release (4.16.x)
+
* users that normally want the latest mainline snapshots, but want to avoid them during the busy merge window when most of the changes are done. Those back then thus wanted the latest stable release (4.16.x)
* users that always want to have the latest Linux stable release (4.16.x)
+
* users that just wanted to use the latest Linux stable release (4.16.x)
 
* users that want to check if a problem they face with a Fedora kernel might be due to a patch that Fedora applied to their kernels (4.15.x)
 
* users that want to check if a problem they face with a Fedora kernel might be due to a patch that Fedora applied to their kernels (4.15.x)
  
[[File:Repos-20180419.png|thumb|Kernel vanilla repositories on 20180409]] And that's why there are four repos, to serve each of those users:  
+
[[File:Repos-20180419.png|thumb|Kernel vanilla repositories on 20180409]] And that's why there are four repositories, to serve each of those users:
  
* the mainline repo shipped the a mainline snapshot (4.17-pre-rc1)
+
* the mainline repo shipped a mainline snapshot (4.17-pre-rc1).
* the mainline-wo-mergew repo shipped the latest stable release (4.16.1, but will jump to 4.17-rc1 once it's released)
+
* the mainline-wo-mergew repo shipped the latest stable release (4.16.1, but will jump to 4.17-rc1 once it's released).
* the stable repo als shipped the latest stable release (4.16.1) (the rpms are hardlinked to save space)
+
* the stable repo also shipped the latest stable release (4.16.1) (side note: the RPM packages are hardlinked to save space).
* the fedora repos shipped a vanilla build of the kernel version that release is using; hence F29/rawhide has a mainline snapshot  (4.17-pre-rc1), F28 has the lastest stable release (4.16.1) and F27 and F26 still have the stable release from the previous version line (4.15.16)
+
* the fedora repo shipped a vanilla build of the kernel version that release is using; hence F29/rawhide has a mainline snapshot  (4.17-pre-rc1), F28 has the lastest stable release (4.16.1) and F27 and F26 still have the stable release from the previous version line (4.15.16).
  
Two or three weeks later F26 and F27 had made the jump to 4.16 and the merge window was over. Then the mainline and mainline-wo-mergew repo both shipped a 4.17 prerelease; the satble and the fedora repos both ship a 4.16.x kernel.
+
Two or three weeks later F26 and F27 had made the jump to 4.16 and the merge window was over. Then the mainline and mainline-wo-mergew repo both shipped a 4.17 prerelease; the stable and the fedora repos both ship a 4.16.x kernel.
  
 
== Can we trust the people behind it? ==
 
== Can we trust the people behind it? ==
Line 57: Line 61:
 
== Thorsten, do you use the vanilla kernels yourself? ==
 
== Thorsten, do you use the vanilla kernels yourself? ==
  
Yes, I normally use the x86-64 vanilla kernels from the mainline repository, but I don't boot into each of them.
+
Yes, I normally use the x86-64 vanilla kernels from the mainline repository on the current or beta Fedora release, but I don't boot into each of them.
  
 
== Are the kernels safe to use? ==
 
== Are the kernels safe to use? ==
Line 63: Line 67:
 
That depends on your definition of 'safe'.  
 
That depends on your definition of 'safe'.  
  
The Linux kernel is a complex piece of software and thus contains bugs. Those bugs lead to data loss now and then; in very rare situations they even damaged 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 there is still a very small chance that things like that can happen. Note that 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.
+
The Linux kernel is a complex piece of software and thus contains bugs. Those bugs lead to data loss a few times in the past; in very rare situations they even damaged 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 there is still a very small chance that things like that can happen.  
  
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.
+
Note that 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.
 +
 
 +
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 current backups at hand, as you always should.
  
 
== Will everything work with the vanilla kernels that works with the official Fedora kernels? ==
 
== Will everything work with the vanilla kernels that works with the official Fedora kernels? ==
Line 71: Line 77:
 
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.
 
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.
  
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 now uses a solution from the upstream kernel for its work.  
+
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 it should work these days, as Systemtap now uses a solution from the upstream kernel for its work).  
  
 
Another example: The kernels from Fedora sometimes include fresher drivers which some systems will require to work properly.  
 
Another example: The kernels from Fedora sometimes include fresher drivers which some systems will require to work properly.  
Line 95: Line 101:
 
== Will this repository also ship updates userland components like drivers or udev that match the kernels in the repositories? ==
 
== 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.
+
No, as there should be no need to, as the interfaces between the kernel and userland software should never change in incompatible ways; Linus Torvalds makes this pretty clear every so often.
  
 
That is the long story short. There are situations where the world is more complicated:
 
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.  
 
* 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
+
* 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:
 
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
+
* 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
+
* in rare cases fixing security problems was only possible my changing the interfaces in incompatible ways.
* sometimes nobody notices early enough that interfaces have changed and reverting the change might break systems that already rely on the new behaviour.
+
* sometimes nobody notices early enough that interfaces have changed and reverting the change might break systems that already rely on the new behavior.
  
 
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.
 
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 longterm kernels ==
+
== Do you plan to provide packages for Longterm kernels ==
 +
 
 +
Unlikely. The main goal of the kernel vanilla repositories for Fedora is to help upstream kernel development; but Longterm kernels are a dead end and quite a bit away from mainline development, so they would not fit that well.
  
Unlikely. The main goal of the kernel vanilla repositories for Fedora is to help upstream kernel development; but longterm kernels are a dead end and quite a bit away from mainline development, so they would not fit that well.  
+
Using a Linux kernel version that is from a older version line than the one used by Fedora also increases the risk that something works worse, so it's possible to argue that this idea most of the time doesn't make sense.
  
Additionally, the Linux versions shipped in this repos are normally newer than what Fedora shipswith, thus Dnf automatically prefers the kernel packages from this repo. Shipping older versions would only work if you change the repositories configuration on your systems to ignore all the kernels that Fedora ships in its repositories. That is not hard, but makes things more complicated. Using a Linux kernel from a older version line than the one used by Fedora also increases the risk that something works worse with our kernel packages.
+
Additionally, the RPM packages shipped in these repositories normally have a higher version number then the kernel packages that Fedora ships with, thus Dnf automatically will prefer the kernel packages from this repo. Shipping older versions would only work for users that change the repositories definitions Fedora provides (fedora.repo; fedora-updates.repo, …) to ignore all the kernels that Fedora ships in its repositories. That is not hard, but makes things more complicated.  
  
 
== Why are there no stable and mainline-wo-mergew repos for rawhide? ==
 
== Why are there no stable and mainline-wo-mergew repos for rawhide? ==
  
Those kernel version would be older than the ones used in Fedora rawhide. That is something we try to avoid for now (see above answer to "Do you plan to provide packages for longterm kernels" for details).
+
Those versions would be older than the ones used in Fedora rawhide. That is something we try to avoid for now (see above answer to "Do you plan to provide packages for longterm kernels" for details).
  
 
== Do you plan to provide packages for "linux-next" or "linux-rt" as well? ==
 
== 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.  
+
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.
 
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 or stable series. Hence it might be wise to leave -next to people that build kernels themselves.
+
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 or 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.
 
[[user:thl|Get in contact]] if you think investing time in these areas makes sense.
Line 142: Line 150:
 
== Why don't you put these kernels in Fedoras main repositories ==
 
== 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.  
+
The current consensus in the Fedora project as far as we see and know 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 [http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org the Fedora devel mailing list], we'll watch and might jump in.
 
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 [http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org the Fedora 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.
+
Putting the kernels in a well know 3rd party add-on repository for Fedora might make sense, but some problems would be similar. It would also lead to more problems, as then users might ask said 3rd party repos to build add-on modules packages 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.
+
The best approach would be to reduce the number of patches the Fedora kernel developers include for one reason or another down to zero or something very close to taht. That would require changes not only in Fedora, but in the upstream workflow as well.
  
 
== Are those kernels really unpatched? ==
 
== Are those kernels really unpatched? ==
  
No, they contain a handful of very small changes that are needed for packaging.  
+
Normally yes.
 +
 
 +
From time to time the packages  but  need to contain a handful of very small changes that are needed for packaging.  
  
From time to time the packages might use patches which temporary are necessary to make the kernel build or usable for 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.
+
might use patches which temporary are necessary to make the kernel build or usable for 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? ==
 
== 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.
+
Most of the time they are quite up2date and only a day or two behind at max. 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, which will lead to a bigger lag.
 
 
== Why are there no stable or mainline-wo-mergew repos for rawhide? ==
 
 
 
We don't bother with those, as those kernel would be older than the ones that rawhide serves.
 
  
 
= FAQ for contributors and developers =
 
= FAQ for contributors and developers =
Line 170: Line 176:
 
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!
 
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? ==
+
== Is there a Git tree with the stuff used to build the SRPM somewhere? ==
  
Sure: [http://fedorapeople.org/cgit/thl/public_git/kernel.git/ http://fedorapeople.org/cgit/thl/public_git/kernel.git/]. Kernels in the kernel-vanilla-mainline repository are normally build from the rawhide branch. Kernels in the kernel-vanilla-fedora repository are always build from the appropriate Fedora branch. Most of the time the kernels in the kernel-vanilla-stable repository come from here to, but sometimes they are build from the stabilization branch.
+
Sure: [http://fedorapeople.org/cgit/thl/public_git/kernel.git/ http://fedorapeople.org/cgit/thl/public_git/kernel.git/]. Kernels in the kernel-vanilla-mainline repository are normally built from the rawhide branch. Kernels in the kernel-vanilla-fedora repository are always built from the appropriate Fedora branch. Most of the time the kernels in the kernel-vanilla-stable repository come from here to, but sometimes they are build from the stabilization or transition branch.
  
 
Let us know if we should do modifications to allow others to contribute to or benefit from this git tree better.
 
Let us know if we should do modifications to allow others to contribute to or benefit from this git tree better.
Line 182: Line 188:
 
== Why are there no debug kernels and not even debuginfo packages ==
 
== Why are there no debug kernels and not even debuginfo packages ==
  
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 and thus downloading the koji results and uploading the final repo take a lot longer.
+
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 and thus downloading the koji results (for testing) and uploading the final repo take a lot longer.
  
 
If you need the debuginfo packags consider rebuilding the SRPM with "rpmbuild -bb --with debuginfo" and installing the results. You can also rebuild the SRPM using "rpmbuild -bb --with dbgonly" in case you need a kernel image where all sorts of debug options are enabled in the configuration.
 
If you need the debuginfo packags consider rebuilding the SRPM with "rpmbuild -bb --with debuginfo" and installing the results. You can also rebuild the SRPM using "rpmbuild -bb --with dbgonly" in case you need a kernel image where all sorts of debug options are enabled in the configuration.
Line 200: Line 206:
 
== Do you work together with the developers that maintain Fedora's kernel packages? ==
 
== 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.
+
There is cooperation already. If you think more is needed in some areas let us know.
  
 
== Please stop providing alternative kernel packages, they take attention away from the kernel packages Fedora provide and thus harm Fedora! ==
 
== Please stop providing alternative kernel packages, they take attention away from the kernel packages Fedora provide and thus harm Fedora! ==
Line 206: Line 212:
 
That's a valid concern, but we think the benefits outweigh the downsides.
 
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.  
+
That again that is the long story short. Just to get a little 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? ==
 
== 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? ==
Line 212: Line 218:
 
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:
 
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
+
* nearly every other repository in Fedoraland that ships variants of packages that are included in Fedora do not change the name.
* the postfix in the name breaks some tools – for example things like 'fedpkg srpm' on the git checkout
+
* the postfix in the name breaks some tools – 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
+
* 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.
* DNF might 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
+
* DNF might 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.

Latest revision as of 07:16, 16 December 2019

Frequently asked questions about the kernel vanilla repositories for Fedora.

Contents

FAQ for users

What's the goal of these repositories?

The main ideas is to help upstream development, which in the end will benefit Fedora as well.

  • With the packages from the kernel-vanilla-mainline repository it for example is quite easy to test kernels that are still under development. Bugs thus can be found early and reported and fixed upstream way before they enter a Linux kernel version shipped as a proper update in Fedora.
  • The kernels from the kernel-vanilla-fedora repository make it easy to check if a bug that happens with a Fedora kernel is present upstream or caused by the patches the Fedora developers apply.
  • The kernels from the kernel-vanilla-stable repositories make it easy to check if a particular bug still happens with the latest stable kernel.

In general, these kernels make it easier to directly interact with upstream developers. That way users don't have to go through the sometimes overworked and quite busy developers that maintain the Linux kernel packages in Fedora.

Are the kernels from the kernel-vanilla repositories as good as those Fedora provides?

No. There are several reasons for why not; the most important ones:

  • the kernels that get used in Fedora or released as proper update get a lot of testing before getting shipped as proper update. The kernels from the kernel vanilla repositories get nearly no testing; they are only started in virtual machine and published as long as they boot there.
  • the official Fedora kernels sometimes contain changes that fix security problems or other crucial bugs before the fix gets merged upstream.
  • the developers that take care of the kernel package in Fedora are far more experienced developers than those that take care of the kernel-vanilla repositories.

In addition, it should be obvious that kernels from the mainline repository are typically still under heavy development and occasionally might have serious bugs that in rare cases can even lead to data loss. But in the end using the kernels from the kernel-vanilla repositories should not be anymore dangerous than downloading a Linux version from kernel.org and compiling and installing it source yourself.

Why so many repos? This looks stupid and over-engineered!

Yes, it might look over-engineered on the first sight, but allows us to serve users with just what they want; and once you look closer you'll notice that most of the time those four repositories contain only two Linux kernel versions per Fedora release.

Kernel.org frontpage on 2018-04-09

To explain this a bit more lets for example take a look April 9th, 2018. Back then…

  • Linux 4.16 was one week old and the first stable release 4.16.1 had just been released.
  • Linux 4.17 had one week into development, thus Linux 4.17-rc1 was still one week away.
  • Linux 4.15.x was still supported upstream and 4.15.16 had just been released.

At the same time…

  • Fedora 29 was Rawhide and contained a mainline snapshot (4.17-pre-rc1).
  • Fedora 28 was in Beta and contained 4.16.x.
  • Fedora 27 and 26 were the current releases and contained a Kernel based on Linux 4.15.x.

In this particular point in time there were…

  • users that want the latest mainline snapshots (4.17-pre-rc1)
  • users that normally want the latest mainline snapshots, but want to avoid them during the busy merge window when most of the changes are done. Those back then thus wanted the latest stable release (4.16.x)
  • users that just wanted to use the latest Linux stable release (4.16.x)
  • users that want to check if a problem they face with a Fedora kernel might be due to a patch that Fedora applied to their kernels (4.15.x)
Kernel vanilla repositories on 20180409

And that's why there are four repositories, to serve each of those users:

  • the mainline repo shipped a mainline snapshot (4.17-pre-rc1).
  • the mainline-wo-mergew repo shipped the latest stable release (4.16.1, but will jump to 4.17-rc1 once it's released).
  • the stable repo also shipped the latest stable release (4.16.1) (side note: the RPM packages are hardlinked to save space).
  • the fedora repo shipped a vanilla build of the kernel version that release is using; hence F29/rawhide has a mainline snapshot (4.17-pre-rc1), F28 has the lastest stable release (4.16.1) and F27 and F26 still have the stable release from the previous version line (4.15.16).

Two or three weeks later F26 and F27 had made the jump to 4.16 and the merge window was over. Then the mainline and mainline-wo-mergew repo both shipped a 4.17 prerelease; the stable and the fedora repos both ship a 4.16.x kernel.

Can we trust the people behind it?

You have to decide yourself. 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 crappy packages 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).

Thorsten, do you use the vanilla kernels yourself?

Yes, I normally use the x86-64 vanilla kernels from the mainline repository on the current or beta Fedora release, but I don't boot into each of them.

Are the kernels safe to use?

That depends on your definition of 'safe'.

The Linux kernel is a complex piece of software and thus contains bugs. Those bugs lead to data loss a few times in the past; in very rare situations they even damaged 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 there is still a very small chance that things like that can happen.

Note that 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.

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 current backups at hand, as you always should.

Will everything work with the vanilla kernels that works with the official Fedora kernels?

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.

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 it should work these days, as Systemtap now uses a solution from the upstream kernel for its work).

Another example: The kernels from Fedora sometimes include fresher drivers which some systems will require to work properly.

Furthermore, in a few cases 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 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 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 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 incompatible ways; Linus Torvalds makes this pretty clear every so often.

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 incompatible ways.
  • sometimes nobody notices early enough that interfaces have changed and reverting the change might break systems that already rely on the new behavior.

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 Longterm kernels

Unlikely. The main goal of the kernel vanilla repositories for Fedora is to help upstream kernel development; but Longterm kernels are a dead end and quite a bit away from mainline development, so they would not fit that well.

Using a Linux kernel version that is from a older version line than the one used by Fedora also increases the risk that something works worse, so it's possible to argue that this idea most of the time doesn't make sense.

Additionally, the RPM packages shipped in these repositories normally have a higher version number then the kernel packages that Fedora ships with, thus Dnf automatically will prefer the kernel packages from this repo. Shipping older versions would only work for users that change the repositories definitions Fedora provides (fedora.repo; fedora-updates.repo, …) to ignore all the kernels that Fedora ships in its repositories. That is not hard, but makes things more complicated.

Why are there no stable and mainline-wo-mergew repos for rawhide?

Those versions would be older than the ones used in Fedora rawhide. That is something we try to avoid for now (see above answer to "Do you plan to provide packages for longterm kernels" for details).

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 or stable series. Hence, it might be wise to leave -next to people that build kernels themselves.

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 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, get in contact.

What configuration do those kernels use?

The mainline kernels use basically the same configuration as the Fedora rawhide kernels. 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.

The stable kernels typically use a configuration that is close to the kernel in the particular Fedora release.

Why don't you put these kernels in Fedoras main repositories

The current consensus in the Fedora project as far as we see and know 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 the Fedora 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 problems would be similar. It would also lead to more problems, as then users might ask said 3rd party repos to build add-on modules packages 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 or something very close to taht. That would require changes not only in Fedora, but in the upstream workflow as well.

Are those kernels really unpatched?

Normally yes.

From time to time the packages but need to contain a handful of very small changes that are needed for packaging.

might use patches which temporary are necessary to make the kernel build or usable for 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?

Most of the time they are quite up2date and only a day or two behind at max. 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, which will lead to a bigger lag.

FAQ 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 with the stuff used to build the SRPM somewhere?

Sure: http://fedorapeople.org/cgit/thl/public_git/kernel.git/. Kernels in the kernel-vanilla-mainline repository are normally built from the rawhide branch. Kernels in the kernel-vanilla-fedora repository are always built from the appropriate Fedora branch. Most of the time the kernels in the kernel-vanilla-stable repository come from here to, but sometimes they are build from the stabilization or transition branch.

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

Why are there no debug kernels and not even debuginfo packages

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 and thus downloading the koji results (for testing) and uploading the final repo take a lot longer.

If you need the debuginfo packags consider rebuilding the SRPM with "rpmbuild -bb --with debuginfo" and installing the results. You can also rebuild the SRPM using "rpmbuild -bb --with dbgonly" in case you need a kernel image where all sorts of debug options are enabled in the configuration.

Let us know if there is interest in these packages, then maybe a solution can be found to provide these packages sooner or later.

Why don't you commit your changes to Fedora's kernel git repo on pkgs.fedoraproject.org?

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.

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. 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 areas 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 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 packages that are included in Fedora do not change the name.
  • the postfix in the name breaks some tools – 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.
  • DNF might 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.