Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #63472 > unrolled thread
| Started by | riccardo.murri@gmail.com |
|---|---|
| First post | 2019-03-01 12:10 +0100 |
| Last post | 2019-03-02 00:30 +0100 |
| Articles | 4 — 4 participants |
Back to article view | Back to linux.debian.kernel
Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules riccardo.murri@gmail.com - 2019-03-01 12:10 +0100
Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules Ben Hutchings <ben@decadent.org.uk> - 2019-03-02 00:30 +0100
Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules Riccardo Murri <riccardo.murri@gmail.com> - 2019-03-04 09:50 +0100
Processed: Re: Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules "Debian Bug Tracking System" <owner@bugs.debian.org> - 2019-03-02 00:30 +0100
| From | riccardo.murri@gmail.com |
|---|---|
| Date | 2019-03-01 12:10 +0100 |
| Subject | Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules |
| Message-ID | <xwOdb-Ss-5@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2019-03-02 00:30 +0100 |
| Message-ID | <xwZLj-7Mb-3@gated-at.bofh.it> |
| In reply to | #63472 |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [prev] | [next] | [standalone]
| From | Riccardo Murri <riccardo.murri@gmail.com> |
|---|---|
| Date | 2019-03-04 09:50 +0100 |
| Message-ID | <xxRsl-7Fn-1@gated-at.bofh.it> |
| In reply to | #63473 |
> > 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
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2019-03-02 00:30 +0100 |
| Subject | Processed: Re: Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules |
| Message-ID | <xwZLk-7Mb-15@gated-at.bofh.it> |
| In reply to | #63472 |
Processing control commands: > severity -1 minor Bug #923522 [linux-image-4.9.0-8-amd64] Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules Severity set to 'minor' from 'normal' -- 923522: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923522 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web