Hello all,
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is essentially DKMS except that instead of just building the kernel module, it'll build a kernel module package that matches an exact kernel release. Some of the weird problems that happen with DKMS don't seem to happen with akmod because of this. There's an argument for the akmod functionality being part of RPM and perhaps that should be the case. In any case, I don't see any particular reason akmod couldn't be brought into Fedora.
On the other end, we have Koschei, which tracks and rebuilds things automatically (but doesn't submit automatically). It should be possible to adapt what Koschei does to be able to automatically generate new kmod packages tied to a particular kernel release and make it easy for a maintainer to turn that into something that can be submitted as part of a kernel update bundle to Bodhi.
The biggest blocker I know of with kmods (at least dkms and akmod style ones) is we have a bug where DNF picks the wrong kernel-devel package at depsolve time[0] (this also appears to affect installing kernel-modules-extras too).
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
Best regards, Neal
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897
Am 14.01.2016 um 16:56 schrieb Neal Gompa:
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is a dirty hack and fails often enough for rpmfusion stuff
additionally you should *never* need GCC and devel packages installed on a normal enduser system for a ton of reasons
On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.01.2016 um 16:56 schrieb Neal Gompa:
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is a dirty hack and fails often enough for rpmfusion stuff
additionally you should *never* need GCC and devel packages installed on a normal enduser system for a ton of reasons
The most common reason that akmod fails is the same reason dkms often fails: the correct kernel-devel isn't installed. For whatever reason, there's no logic in DNF to handle this case properly. Of course, to be fair, this problem happens in Yum too, but since Yum isn't actively supported in Fedora anymore, it's not as much of a concern.
Am 14.01.2016 um 18:05 schrieb Neal Gompa:
On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.01.2016 um 16:56 schrieb Neal Gompa:
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is a dirty hack and fails often enough for rpmfusion stuff
additionally you should *never* need GCC and devel packages installed on a normal enduser system for a ton of reasons
The most common reason that akmod fails is the same reason dkms often fails: the correct kernel-devel isn't installed. For whatever reason, there's no logic in DNF to handle this case properly. Of course, to be fair, this problem happens in Yum too, but since Yum isn't actively supported in Fedora anymore, it's not as much of a concern.
no, the most common reason is that whatever should don't build aganinst a recent fedora kernel
2016-01-14 18:05 GMT+01:00 Neal Gompa ngompa13@gmail.com:
On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.01.2016 um 16:56 schrieb Neal Gompa:
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is a dirty hack and fails often enough for rpmfusion stuff
additionally you should *never* need GCC and devel packages installed on
a
normal enduser system for a ton of reasons
The most common reason that akmod fails is the same reason dkms often fails: the correct kernel-devel isn't installed. For whatever reason, there's no logic in DNF to handle this case properly. Of course, to be fair, this problem happens in Yum too, but since Yum isn't actively supported in Fedora anymore, it's not as much of a concern.
Maybe this particular concern can be addressed in DNF with a plugin ?
The way I've previously worded a possible solution is to have a yum/dnf plugin for akmod. This plugin will select the appropriate kernel-devel based on the kernel that is currently installed. ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
But this dnf plugin can be useful by default in fedora, since the kernel-devel issue can rise when one user install a particular development group where kernel-devel is needed. (user typically ends with kernel-debug-devel instead of the one for their kernel variant that can also be kernel-lpae or else).
- Nicolas
On Jan 14, 2016 9:34 AM, "Nicolas Chauvet" kwizart@gmail.com wrote:
2016-01-14 18:05 GMT+01:00 Neal Gompa ngompa13@gmail.com:
On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald h.reindl@thelounge.net
wrote:
Am 14.01.2016 um 16:56 schrieb Neal Gompa:
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is a dirty hack and fails often enough for rpmfusion stuff
additionally you should *never* need GCC and devel packages installed
on a
normal enduser system for a ton of reasons
The most common reason that akmod fails is the same reason dkms often fails: the correct kernel-devel isn't installed. For whatever reason, there's no logic in DNF to handle this case properly. Of course, to be fair, this problem happens in Yum too, but since Yum isn't actively supported in Fedora anymore, it's not as much of a concern.
Maybe this particular concern can be addressed in DNF with a plugin ?
The way I've previously worded a possible solution is to have a yum/dnf
plugin for akmod.
This plugin will select the appropriate kernel-devel based on the kernel
that is currently installed.
( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
But this dnf plugin can be useful by default in fedora, since the
kernel-devel issue can rise when one user install a particular development group where kernel-devel is needed.
(user typically ends with kernel-debug-devel instead of the one for their
kernel variant that can also be kernel-lpae or else).
There are two issues here, I think:
1. Is Fedora okay, in principle, with shipping out-of-tree modules?
I won't comment on #1. (I also won't comment on Secure Boot issues.)
2. Assuming that shipping an out-of-tree module is okay, is akmod a good mechanism?
I would argue strongly that akmod is *not* a good mechanism.
Clearly any end-user-box-builds-modules system needs the package manager to pull in the right devel stuff. This is clearly a solvable problem.
But akmod in particular has a really nasty built-in assumption: it assumes that the running kernel came from an RPM at all. For people who write kernels, this utterly sucks. For example, I have no intention of rpm-ifying every test kernel I build for my laptop. I install them according to the standard arrangement, which "make install" can do just fine. There are symlinks in standard places that a kmod build system could find. Akmod can't do that. Akmod also can't figure out what to make its freshly-built rpm depend on because there is no correct answer.
I think that, if Fedora were to adopt a kmod build system: it should have a QA requirement: if you "make modules_install && make install" a kernel and boot into it, the kmod system should work. Akmod fails utterly in that scenario.
--Andy
On 14 January 2016 at 19:29, Andrew Lutomirski luto@mit.edu wrote:
On Jan 14, 2016 9:34 AM, "Nicolas Chauvet" kwizart@gmail.com wrote:
2016-01-14 18:05 GMT+01:00 Neal Gompa ngompa13@gmail.com:
On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.01.2016 um 16:56 schrieb Neal Gompa:
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is a dirty hack and fails often enough for rpmfusion stuff
additionally you should *never* need GCC and devel packages installed on a normal enduser system for a ton of reasons
The most common reason that akmod fails is the same reason dkms often fails: the correct kernel-devel isn't installed. For whatever reason, there's no logic in DNF to handle this case properly. Of course, to be fair, this problem happens in Yum too, but since Yum isn't actively supported in Fedora anymore, it's not as much of a concern.
Maybe this particular concern can be addressed in DNF with a plugin ?
The way I've previously worded a possible solution is to have a yum/dnf plugin for akmod. This plugin will select the appropriate kernel-devel based on the kernel that is currently installed. ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
But this dnf plugin can be useful by default in fedora, since the kernel-devel issue can rise when one user install a particular development group where kernel-devel is needed. (user typically ends with kernel-debug-devel instead of the one for their kernel variant that can also be kernel-lpae or else).
There are two issues here, I think:
- Is Fedora okay, in principle, with shipping out-of-tree modules?
I won't comment on #1. (I also won't comment on Secure Boot issues.)
- Assuming that shipping an out-of-tree module is okay, is akmod a good
mechanism?
I would argue strongly that akmod is *not* a good mechanism.
Clearly any end-user-box-builds-modules system needs the package manager to pull in the right devel stuff. This is clearly a solvable problem.
But akmod in particular has a really nasty built-in assumption: it assumes that the running kernel came from an RPM at all. For people who write kernels, this utterly sucks. For example, I have no intention of rpm-ifying every test kernel I build for my laptop. I install them according to the standard arrangement, which "make install" can do just fine. There are symlinks in standard places that a kmod build system could find. Akmod can't do that. Akmod also can't figure out what to make its freshly-built rpm depend on because there is no correct answer.
I think that, if Fedora were to adopt a kmod build system: it should have a QA requirement: if you "make modules_install && make install" a kernel and boot into it, the kmod system should work. Akmod fails utterly in that scenario.
I don't quite get this one, if you build any package from a non-rpm source it's not a given that rpm modules will work with it. Akmod is really a convenience for people reliant on non-tree modules who are also using the distribution rpm kernel, so they have a chance of getting a working module whenever the kernel updates. If you're building your own kernel you probably know when you've done it and how to build the module.
On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 01/14/2016 07:56 AM, Neal Gompa wrote:
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
If you have secure boot, you have to go through the process to sign the kernel modules you build and register the key with the boot system.
That would be something our build system (Koji, etc.) would handle if we allowed them again, right? After all, I believe Koji handles our kernel signing, too.
Am 14.01.2016 um 19:54 schrieb Neal Gompa:
On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 01/14/2016 07:56 AM, Neal Gompa wrote:
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
If you have secure boot, you have to go through the process to sign the kernel modules you build and register the key with the boot system.
That would be something our build system (Koji, etc.) would handle if we allowed them again, right? After all, I believe Koji handles our kernel signing, too.
how do you imagine in real life maintaining kmod's by different people and maintaining the kernel by others?
there are often timeframes where you get each week and in rare cases twice a week a kernel update - have fun to coordinate that!
and *no* hold back kernel updates for crap hardware not supported by the mainline kernel or burden the kernel package-maintainer the additional work is no solution
i don't want to get my kernel pushed with a delay because of other packages i don't care because a few users don#t think before by computers
On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 01/14/2016 07:56 AM, Neal Gompa wrote:
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
If you have secure boot, you have to go through the process to sign the kernel modules you build and register the key with the boot system.
That would be something our build system (Koji, etc.) would handle if we allowed them again, right? After all, I believe Koji handles our kernel signing, too.
No, it would not.
The kernel modules are signed with an ephemeral cert as part of the kernel build process. They are not signed with the Fedora cert used for Secure Boot. The vmlinuz and grub2 binaries are signed with the Secure Boot cert. The tool that does the signing only works with PECoff binaries and the kernel modules are not PECoff.
So no, the build system does not support signing modules outside of the normal kernel build.
josh
On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 01/14/2016 07:56 AM, Neal Gompa wrote:
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
If you have secure boot, you have to go through the process to sign the kernel modules you build and register the key with the boot system.
That would be something our build system (Koji, etc.) would handle if we allowed them again, right? After all, I believe Koji handles our kernel signing, too.
No, it would not.
The kernel modules are signed with an ephemeral cert as part of the kernel build process. They are not signed with the Fedora cert used for Secure Boot. The vmlinuz and grub2 binaries are signed with the Secure Boot cert. The tool that does the signing only works with PECoff binaries and the kernel modules are not PECoff.
So no, the build system does not support signing modules outside of the normal kernel build.
So that would mean in order to make kernel modules build to work outside of the kernel build process, we would need a way to add more certs that would be accepted by the kernel and grub, right? I assume you'd want to do the ephemeral cert process for kmod builds too?
On Thu, Jan 14, 2016 at 2:09 PM, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 01/14/2016 07:56 AM, Neal Gompa wrote:
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
If you have secure boot, you have to go through the process to sign the kernel modules you build and register the key with the boot system.
That would be something our build system (Koji, etc.) would handle if we allowed them again, right? After all, I believe Koji handles our kernel signing, too.
No, it would not.
The kernel modules are signed with an ephemeral cert as part of the kernel build process. They are not signed with the Fedora cert used for Secure Boot. The vmlinuz and grub2 binaries are signed with the Secure Boot cert. The tool that does the signing only works with PECoff binaries and the kernel modules are not PECoff.
So no, the build system does not support signing modules outside of the normal kernel build.
So that would mean in order to make kernel modules build to work outside of the kernel build process, we would need a way to add more certs that would be accepted by the kernel and grub, right? I assume you'd want to do the ephemeral cert process for kmod builds too?
If you are creating a cert to sign the out-of-tree modules and expect it to be accepted by the kernel, it cannot be ephemeral. A user would need someway to import it into their kernel or have it passed from grub. The only way to do so is to have it embedded in shim or the kernel during the build of those binaries. I do not foresee Fedora creating yet another persistent key to sign things with, which means you would need another tool that can use the existing key in the kernel builders.
Except there are only 4 people that can submit builds to those builders for security purposes (which is why scratch builds are unsigned), and I don't see any of the existing maintainers signing up to submit kmod builds.
So no, our buildsystem cannot sign kmods.
josh
Josh Boyer wrote:
If you are creating a cert to sign the out-of-tree modules and expect it to be accepted by the kernel, it cannot be ephemeral. A user would need someway to import it into their kernel or have it passed from grub. The only way to do so is to have it embedded in shim or the kernel during the build of those binaries. I do not foresee Fedora creating yet another persistent key to sign things with, which means you would need another tool that can use the existing key in the kernel builders.
That just proves that Restricted Boot and especially our implementation of it (requiring kernel modules to be signed) is a very bad thing.
Kevin Kofler
----- Original Message -----
Josh Boyer wrote:
If you are creating a cert to sign the out-of-tree modules and expect it to be accepted by the kernel, it cannot be ephemeral. A user would need someway to import it into their kernel or have it passed from grub. The only way to do so is to have it embedded in shim or the kernel during the build of those binaries. I do not foresee Fedora creating yet another persistent key to sign things with, which means you would need another tool that can use the existing key in the kernel builders.
That just proves that Restricted Boot and especially our implementation of it (requiring kernel modules to be signed) is a very bad thing.
How do you expect to be able to ensure that the kernel only loads "known good" modules if you can insert random modules that might subvert SecureBoot and all that it allows to secure?
On Feb 22, 2016 6:33 AM, "Bastien Nocera" bnocera@redhat.com wrote:
----- Original Message -----
Josh Boyer wrote:
If you are creating a cert to sign the out-of-tree modules and expect it to be accepted by the kernel, it cannot be ephemeral. A user would need someway to import it into their kernel or have it passed from grub. The only way to do so is to have it embedded in shim or the kernel during the build of those binaries. I do not foresee Fedora creating yet another persistent key to sign things with, which means you would need another tool that can use the existing key in the kernel builders.
That just proves that Restricted Boot and especially our implementation
of
it (requiring kernel modules to be signed) is a very bad thing.
How do you expect to be able to ensure that the kernel only loads "known
good"
modules if you can insert random modules that might subvert SecureBoot and all that it allows to secure?
I still find it confusing that Fedora will let you do anything you want in userspace but will not let you load your own kernel module. This may or may not be required by MS and/or UEFI Forum rules (I honestly have no idea, and I recall that jejb was going to discuss this at some point but I don't think it ever happened). Regardless, I don't see a credible widely-applicable threat model under which this is useful.
Would Fedora be permitted to simply drop the signed module requirement?
ISTM a genuinely useful approach might be to forcibly extend some PCR and maybe blank out some keyrings if an unsigned module is loaded.
--Andy
Bastien Nocera bnocera@redhat.com writes:
If you are creating a cert to sign the out-of-tree modules and expect it to be accepted by the kernel, it cannot be ephemeral. A user would need someway to import it into their kernel or have it passed from grub. [...]
That just proves that Restricted Boot and especially our implementation of it (requiring kernel modules to be signed) is a very bad thing.
How do you expect to be able to ensure that the kernel only loads "known good" modules if you can insert random modules that might subvert SecureBoot and all that it allows to secure?
For systemtap on secureboot systems, we rely on Machine Owner Keys. These keys are generated once. The public half is put into UEFI via mokutil and a reboot. The private half held at another trusted machine. Then that machine can sign modules with the MOK key and have normal Fedora kernels/shims accept them.
- FChE
Am 14.01.2016 um 20:09 schrieb Neal Gompa:
On Thu, Jan 14, 2016 at 2:00 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 14, 2016 at 1:54 PM, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jan 14, 2016 at 1:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 01/14/2016 07:56 AM, Neal Gompa wrote:
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
If you have secure boot, you have to go through the process to sign the kernel modules you build and register the key with the boot system.
That would be something our build system (Koji, etc.) would handle if we allowed them again, right? After all, I believe Koji handles our kernel signing, too.
No, it would not.
The kernel modules are signed with an ephemeral cert as part of the kernel build process. They are not signed with the Fedora cert used for Secure Boot. The vmlinuz and grub2 binaries are signed with the Secure Boot cert. The tool that does the signing only works with PECoff binaries and the kernel modules are not PECoff.
So no, the build system does not support signing modules outside of the normal kernel build.
So that would mean in order to make kernel modules build to work outside of the kernel build process, we would need a way to add more certs that would be accepted by the kernel and grub, right? I assume you'd want to do the ephemeral cert process for kmod builds too?
it is not supported by the kernel maintainers for a lot of reasons accept it or become "the kernel maintainers"
On Thu, Jan 14, 2016 at 10:56 AM, Neal Gompa ngompa13@gmail.com wrote:
Hello all,
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is essentially DKMS except that instead of just building the kernel module, it'll build a kernel module package that matches an exact kernel release. Some of the weird problems that happen with DKMS don't seem to happen with akmod because of this. There's an argument for the akmod functionality being part of RPM and perhaps that should be the case. In any case, I don't see any particular reason akmod couldn't be brought into Fedora.
On the other end, we have Koschei, which tracks and rebuilds things automatically (but doesn't submit automatically). It should be possible to adapt what Koschei does to be able to automatically generate new kmod packages tied to a particular kernel release and make it easy for a maintainer to turn that into something that can be submitted as part of a kernel update bundle to Bodhi.
The biggest blocker I know of with kmods (at least dkms and akmod style ones) is we have a bug where DNF picks the wrong kernel-devel package at depsolve time[0] (this also appears to affect installing kernel-modules-extras too).
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
The kernel team does not support their inclusion in Fedora. In brief, it is asking to allow an out-of-tree, non-upstream, unreviewed chunk of code into potentially every Fedora install that has no restrictions on what it can do and can easily crash a machine or worse.
If the code in question _was_ reviewed and headed into the upstream kernel tree, the kernel team still would not support building it as a separate stand-alone module. There are buildsystem issues I mentioned in another email, but the plain fact is that in that specific case it simply wouldn't be worth packaging separately. Something clearly on its way upstream would get pulled into the kernel package itself as patches and built with every other module we provide.
This is a major part of why we disallowed them in the past and that was before any of the existing kernel team members were on the team yet. Our stance has not changed over time or with the introduction of new team members.
josh
Josh Boyer wrote:
This is a major part of why we disallowed them in the past and that was before any of the existing kernel team members were on the team yet. Our stance has not changed over time or with the introduction of new team members.
And I still believe that it is wrong to reject modules under licenses compatible with the kernel's GPLv2 license just because they are released separately. We allow out-of-tree plugins for other packages too. (Imagine if all Python modules were required to be built as part of the main Python SRPM.)
That said, for the particular case of the ZFS module that originated this thread, licensing issues preclude shipping it anyway, so in that case, the discussion is moot.
Kevin Kofler
On Thu, 2016-01-14 at 10:56 -0500, Neal Gompa wrote:
Hello all,
I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them.
If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed.
We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules.
akmod is essentially DKMS except that instead of just building the kernel module, it'll build a kernel module package that matches an exact kernel release. Some of the weird problems that happen with DKMS don't seem to happen with akmod because of this. There's an argument for the akmod functionality being part of RPM and perhaps that should be the case. In any case, I don't see any particular reason akmod couldn't be brought into Fedora.
On the other end, we have Koschei, which tracks and rebuilds things automatically (but doesn't submit automatically). It should be possible to adapt what Koschei does to be able to automatically generate new kmod packages tied to a particular kernel release and make it easy for a maintainer to turn that into something that can be submitted as part of a kernel update bundle to Bodhi.
The biggest blocker I know of with kmods (at least dkms and akmod style ones) is we have a bug where DNF picks the wrong kernel-devel package at depsolve time[0] (this also appears to affect installing kernel-modules-extras too).
Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora?
The kernel doesn't have a stable API. Nothing guarantees the kernel module would work with newer kernel version. As is usually the case, it doesn't and it either break user's system or leaves it outdated, both of which are horrible user experience.
Best regards, Neal
-
Andrew Lutomirski -
Bastien Nocera -
Frank Ch. Eigler -
Ian Malone -
Josh Boyer -
Kevin Kofler -
Lubomir Rintel -
Neal Gompa -
Nicolas Chauvet -
Reindl Harald -
Samuel Sieb