Bug 1709940
| Summary: | DKMS runs on reboot instead of as hook | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | rhbz |
| Component: | dkms | Assignee: | Simone Caronni <negativo17> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 30 | CC: | hutter2, James.R.Harris, mail, negativo17, neomp5, ppywlkiqletw, rabin, redhat-bugzilla, rhbz, stefan.van.der.eijk |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-20 00:01:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
rhbz
2019-05-14 15:16:27 UTC
This is annoying behaviour for anything that's needed early in the boot process: - Network drivers (for NFS mounts) - Storage controller drivers in general - File systems I agree that this should be done during kernel install time to make sure the modules needed are present in the initrd. For sure there is room for improvement. DKMS can probably be called with a %trigger in the SPEC file. http://ftp.rpm.org/api/4.4.2.2/triggers.html Both akmods and dkms module packages that I've seen around trigger the build and install at the moment the package is installed/upgraded: https://github.com/negativo17/dkms-nvidia/blob/master/dkms-nvidia.spec#L41-L49 The same approach can also be used in a %trigger section in the kernel module SPEC file. Patches are welcome. I'm a bit puzzled on what the motivation for this change was. Aguably the new behaviour has worse user experience (even if all goes as planned), as the next reboot is delayed while DKMS does its thing. The old behaviour led to longer DNF runtimes, but the system could be used during that time. This new build behaviour may affect ZFS users: https://github.com/zfsonlinux/zfs/issues/8763 This appears to be related to https://bugzilla.redhat.com/show_bug.cgi?id=1696202. Given that dkms on fc30 still installs hooks in /etc/kernel/postinst.d and /etc/kernel/prerm.d yet /usr/bin/kernel-install from systemd left it to /sbin/new-kernel-pkg from grubby to run the postinst and prerm hooks. It seems grubby has lost new-kernel-pkg in fc30. I suspect the install on boot is just dkms being resilient and this was never intended behavior. If systemds kernel-install is the correct place to call /etc/kernel/install.d/ hooks why isn't also required to call /etc/kernel/postinst.d and /etc/kernel/prerm.d hooks? Not sure exactly how to solve it, considering that the DKMS page has not changed. Shall we had a %trigger in the SPEC file to trigger the DKMS autobuild every time a new kernel-devel package is installed? This is all a bit convoluted, as far as I can figure out. The DKMS package drops a file into /etc/kernel/postinst.d/dkms. This file triggers the actual rebuild process when a new kernel gets installed. In F29 and earlier the call chain for this is: /bin/kernel-install (called from the %posttrans in kernel-core packages) /usr/lib/kernel/install.d/20-grubby.install (or /usr/lib/kernel/install.d/20-grub.install) /sbin/new-kernel-pkg /etc/kernel/postinst.d/dkms In F30 /sbin/new-kernel-pkg is no longer a thing, the file doesn't exist. So I guess what has to happen is that DKMS instead has to drop a file into /usr/lib/kernel/install.d/ which triggers the rebuild instead. I'm sure the calling conventions of that file will be different from the /etc/kernel/postinst.d/dkms one, and the order of the scripts in /usr/lib/kernel/install.d/ is important. As I noted this is a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1696202 which was just closed with an update to grubby-8.40-31.fc30. I would suggest closing this bug as a dupe. My unit test of zfs modules show them getting updated (and removed) when kernels are added and removed. *** This bug has been marked as a duplicate of bug 1696202 *** (In reply to Ralf Ertzinger from comment #7) > This is all a bit convoluted, as far as I can figure out. > > The DKMS package drops a file into /etc/kernel/postinst.d/dkms. This file > triggers the actual rebuild process when a new kernel gets installed. > > In F29 and earlier the call chain for this is: > > /bin/kernel-install (called from the %posttrans in kernel-core packages) > /usr/lib/kernel/install.d/20-grubby.install (or > /usr/lib/kernel/install.d/20-grub.install) > /sbin/new-kernel-pkg > /etc/kernel/postinst.d/dkms You can still get the old behaviour by setting "GRUB_ENABLE_BLSCFG=false" in /etc/default/grub, and also install grubby-deprecated. > > In F30 /sbin/new-kernel-pkg is no longer a thing, the file doesn't exist. So > I guess what has to happen is that DKMS instead has to drop a file into > /usr/lib/kernel/install.d/ which triggers the rebuild instead. I'm sure the > calling conventions of that file will be different from the > /etc/kernel/postinst.d/dkms one, and the order of the scripts in > /usr/lib/kernel/install.d/ is important. akmods fixed a similar problem by installing the file /usr/lib/kernel/install.d/95-akmodsposttrans.install (In reply to Villy Kruse from comment #10) > > In F30 /sbin/new-kernel-pkg is no longer a thing, the file doesn't exist. So > > I guess what has to happen is that DKMS instead has to drop a file into > > /usr/lib/kernel/install.d/ which triggers the rebuild instead. I'm sure the > > calling conventions of that file will be different from the > > /etc/kernel/postinst.d/dkms one, and the order of the scripts in > > /usr/lib/kernel/install.d/ is important. > > > akmods fixed a similar problem by installing the file > /usr/lib/kernel/install.d/95-akmodsposttrans.install Thanks, will look into it to see also if it can help for the bug when a new dkms package is installed with a new kernel in the same yum/dnf transaction. I can confirm that installing grubby-8.40-31.fc30 fixes the issue, DKMS modules are built after new kernel install again, I also confirm that the dkms modules are built when a new kernel is installed. When a kernel is removed the dkms modules for that kernel aren't cleaned up. Is a separate bug required to address that? As far as I can tell that has never worked, so it's not new behaviour. That would be a separate bug report. |