[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules



Control: severity -1 minor

On Fri, 2019-03-01 at 12:07 +0100, riccardo.murri@gmail.com wrote:
> Package: linux-image-4.9.0-8-amd64
> Version: 4.9.144-3.1
> 
> As of March 1, 2019, running `apt upgrade` on a recent Debian 9 official
> cloud image, results in package `linux-image-4.9.0-8-amd64` being
> upgraded:
> 
>     $ apt list --upgradable
>     [...]
>     linux-image-4.9.0-8-amd64/stable-updates 4.9.144-3.1 amd64 [upgradable from: 4.9.130-2]
>     [...]
> 
> However, after the upgrade, kernel modules are no longer loadable; here
> is an example triggered by `ip6tables-restore`:
> 
>     # tail /var/log/syslog 
>     Mar  1 10:11:08 stretch kernel: [  502.887305] nf_defrag_ipv6: disagrees about version of symbol inet_frags_fini
>     Mar  1 10:11:08 stretch kernel: [  502.887894] nf_defrag_ipv6: Unknown symbol inet_frags_fini (err -22)
>     Mar  1 10:11:08 stretch kernel: [  502.888985] nf_defrag_ipv6: disagrees about version of symbol inet_frag_find
>     Mar  1 10:11:08 stretch kernel: [  502.889712] nf_defrag_ipv6: Unknown symbol inet_frag_find (err -22)
>     Mar  1 10:11:08 stretch kernel: [  502.890386] nf_defrag_ipv6: disagrees about version of symbol ip6_expire_frag_queue
>     Mar  1 10:11:08 stretch kernel: [  502.891048] nf_defrag_ipv6: Unknown symbol ip6_expire_frag_queue (err -22)
>     Mar  1 10:11:08 stretch kernel: [  502.891885] nf_defrag_ipv6: Unknown symbol pskb_trim_rcsum_slow (err 0)
>     Mar  1 10:11:08 stretch kernel: [  502.893030] nf_defrag_ipv6: disagrees about version of symbol inet_frag_kill
>     Mar  1 10:11:08 stretch kernel: [  502.893688] nf_defrag_ipv6: Unknown symbol inet_frag_kill (err -22)
>     Mar  1 10:11:08 stretch kernel: [  502.894594] xt_conntrack: cannot load conntrack support for proto=10
> 
> 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.

> 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...
>
> Thanks for any help!

Normally all required modules would be loaded during boot, so there's
no breakage.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: