Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
On 2018-02-26 at 14:55, Ben Hutchings wrote: > On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote: >> If the automatic DKMS rebuild is expected to be able to produce >> modules which can work with the running kernel, then clearly the >> current behavior is buggy in some way, and should be addressed. > > I don't think that's a reasonable expectation. But I think DKMS > should not automatically rebuild when installing a version of > linux-headers- ABINAME that is newer than the currently *installed* > version of linux- image-ABINAME. It's possible that it actually doesn't. I believe the rebuild that triggered the problem, for me, was triggered not by an upgrade of linux-headers-ABINAME but by an upgrade of virtualbox-dkms; the linux-headers-* package was upgraded much earlier, I believe on January 21st. (And IIRC the matching linux-image-* package was upgraded at the same time.) Off the top of my head, I don't see any potential way for DKMS to know whether it's being asked to build against the sources of the running kernel, vs. simply the sources of the currently installed kernel - and I'm fairly sure that making the correct decision about whether or not to rebuild when upgrading non-kernel packages would require knowing that. >> On the other hand, if rebuilding the modules is expected to result >> in modules which will not load against the running kernel, >> shouldn't the DKMS machinery detect this condition and refrain from >> automatically removing the existing (working) modules, at least >> without an override request of some sort? Or at bare minimum, warn >> that proceeding with the upgrade will result in functionality loss >> until a reboot can be carried out? > > If by "removing" you mean unloading a module from the kernel, I > agree that it should not do this. The idea of not unloading the module at upgrade time had in fact not occurred to me. It's an interesting one, and if viable would seem to offer a way out of the problem, but I'm not sure how viable it would be in practice. The upgrade process appears to consist basically of an uninstall followed by an install. As such, all three of those scenarios would need to be considered. As far as I can tell without deeper investigation than I'm currently set up for, what DKMS currently does at upgrade is to delete the old modules, build the new ones, unload the old ones, and then load the new ones. (I'm basing this on the output messages during the upgrade; I've dug for the place where the underlying commands get run and the messages get generated, but I haven't found anything I'm confident is the right place.) If there's a way to load the new module without unloading the other first - if, e.g., the kernel will detect the collision and automatically unload the old one after validating the new - it should be possible to have DKMS do that, and skip the unload entirely. However, I don't remember seeing any indication that such a way exists. If there's a way to detect whether the newly-built modules will be compatible with the currently-running kernel before trying to load them, it might be possible to have DKMS skip the unload and subsequent load if the latter would fail. Again, however, I don't know of any such way. If neither of those things is possible, then the choices would seem to be to either never unload (meaning that the old module would remain in use until sysadmin intervention), or always unload (basically the current situation). What DKMS currently does at uninstall time I don't know. Clearly, however, it would need to unload the module, as otherwise the uninstall could not be considered complete. However, it's not clear to me that there's any way for it to be able to tell a "permanent uninstall" removal from an "upgrade" removal. At install time, plainly DKMS needs to load the just-built module, but again it's not clear to me that there's any way for it to tell a "clean install" build from an "upgrade" build. (That said, I've also seen my entire system hardlock when upgrading VirtualBox packages while a VirtualBox VM was running, and it seems very plausible that the lockup was because a module which was in use by VirtualBox got automatically unloaded by DKMS. If it's possible to design so as to avoid that automatic unload, without unacceptable tradeoffs, that would make managing my upgrades easier.) > If you mean replacing the module on disk, I disagree; it should > build modules for the installed kernel version. Certainly it should, and if there's no way to do that without removing the existing modules from the disk, then that's what it should do - possibly with a warning message or even an "are you sure?" prompt, but still. I had thought that the DKMS upgrade-time messages about "module was ACTIVE" and "module version" and "original module" carried the implication that it was possible to have DKMS managing multiple versions of a given module for a given kernel at once, but digging deeper seems to indicate that this f
Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote: [...] > I am still running kernel version 4.14.13-1, although the installed > version of linux-{image,headers}-4.14.0-3-amd64 is 4.14.17-1; I have not > rebooted since upgrading the kernel package, and IMO it should not be > expected that upgrading the kernel will be followed swiftly by a reboot. In the same way that extensions to a library ABI do not require a new soname, extensions to the kernel module ABI do not require a change to its ABI name. Newly built modules, including in-tree modules, may depend on those extensions. Therefore you should not expect to be able to load new kernel modules between upgrading the kernel and rebooting. > To the best of my recollection, I have never previously seen it be > necessary to reboot in order to avoid loss of functionality from a DKMS > rebuild subsequent to a kernel upgrade. I think you've just been lucky. > If the automatic DKMS rebuild is expected to be able to produce modules > which can work with the running kernel, then clearly the current > behavior is buggy in some way, and should be addressed. I don't think that's a reasonable expectation. But I think DKMS should not automatically rebuild when installing a version of linux-headers- ABINAME that is newer than the currently *installed* version of linux- image-ABINAME. > On the other hand, if rebuilding the modules is expected to result in > modules which will not load against the running kernel, shouldn't the > DKMS machinery detect this condition and refrain from automatically > removing the existing (working) modules, at least without an override > request of some sort? Or at bare minimum, warn that proceeding with the > upgrade will result in functionality loss until a reboot can be carried > out? If by "removing" you mean unloading a module from the kernel, I agree that it should not do this. If you mean replacing the module on disk, I disagree; it should build modules for the installed kernel version. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
Or in other words: the unexpected behavior here is on the part of DKMS, in removing working modules when the ones which will be put in as their replacements do not work, not on the part of the kernel headers (et cetera) themselves. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
I encountered this error today on upgrade of virtualbox-dkms, I think from version 5.2.6-dfsg-2 to 5.2.6-dfsg-5. To the best of my knowledge, I have not carried out any downgrade, either of the kernel or of the DKMS package. In my experience, upgrading a DKMS package triggers an automatic rebuild of the relevant module(s) against installed headers; more specifically, on removal of the pre-upgrade version the old modules are removed, and on install of the post-upgrade version the new modules are automatically built. (The messages printed during this process seem to imply that the DKMS machinery has the ability to have multiple installed module versions per kernel, and simply set one or another as active, but I have never seen this functionality be used.) I am still running kernel version 4.14.13-1, although the installed version of linux-{image,headers}-4.14.0-3-amd64 is 4.14.17-1; I have not rebooted since upgrading the kernel package, and IMO it should not be expected that upgrading the kernel will be followed swiftly by a reboot. To the best of my recollection, I have never previously seen it be necessary to reboot in order to avoid loss of functionality from a DKMS rebuild subsequent to a kernel upgrade. If the automatic DKMS rebuild is expected to be able to produce modules which can work with the running kernel, then clearly the current behavior is buggy in some way, and should be addressed. On the other hand, if rebuilding the modules is expected to result in modules which will not load against the running kernel, shouldn't the DKMS machinery detect this condition and refrain from automatically removing the existing (working) modules, at least without an override request of some sort? Or at bare minimum, warn that proceeding with the upgrade will result in functionality loss until a reboot can be carried out? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature