Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules
> > 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
Reply to: