> > The problem is that both packages install kernel modules in the same > > directory `/lib/modules/4.9.0-8-amd64` although they are not binary > > compatible. > > This is a known issue with upgrades that we don't currently plan to > fix.
May I ask why no fix will be considered? > > Needless to say, the issue with loading kernel modules is corrected by a > > reboot, but I think that the larger issue here is that upgrading a > > kernel package, on the *stable* distribution and *keeping the same > > (nominal) kernel version*, can break a running system -- all while that a > > solution for this problem has been known for many years now... > > Normally all required modules would be loaded during boot, so there's > no breakage. I beg to differ. The case which prompted me to report this bug (see [1]) is the following: 1. spin up a cloud-based Debian VM, 2. run `apt upgrade`, *then* 3. install & customize software. If the kernel has to be upgraded, then this can break after step 2.; e.g. you may not be able to run `ip6tables` because IPv6 modules cannot be loaded. Still, I think this kind of usage of cloud-based VMs is common enough to merit some consideration. I can also imagine usage scenarios where this could be an issue with physical servers as well, since it basically breaks "hotplug" functionality -- forcing an immediate reboot after an update. I can understand if the project has already given it consideration and decided that the issue is not worth time spent fixing it or the additional hassle in packaging kernels, but to me it was surprising enough that I think it needs to be documented somehow (e.g. FAQ?): sysadmins should be alerted that you're basically assumed to reboot *immediately* after `apt upgrade`. [1]: https://github.com/gc3-uzh-ch/elasticluster/issues/609
