[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



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.

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!

Riccardo


Reply to: