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 functionality is intended for cases where you're building a replacement for a shipped module, not when building a new module not provided by the shipped kernel. So the idea of simply switching the in-use module to "not ACTIVE" and leaving it on the system, so that the sysadmin can switch back to it if something goes wrong with the built replacement, doesn't look viable on closer examination. -- 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
