Hi Andreas,
thanks for the bug report. Actually I do have a Bookworm system
already running with iptables-netflow-dkms, but it was a fresh
installation on new hardware.
Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'bullseye'.
> It installed fine in 'bullseye' (with linux-headers-amd64
> installed),
Just for clarification: "It" means that the version from bullseye
installed fine on bullseye. From the log you attached:
Unpacking iptables-netflow-dkms (2.6-3.1) over (2.5.1-2) ...
> Setting up iptables-netflow-dkms (2.6-3.1) ...
> Loading new ipt-netflow-2.6 DKMS files...
> It is likely that 5.10.28 belongs to a chroot's host
> Building for 5.10.0-22-amd64 and 6.1.0-7-amd64
> Building initial module for 5.10.0-22-amd64
> Error! Bad return status for module build on kernel: 5.10.0-22-amd64
> (x86_64)
> Consult /var/lib/dkms/ipt-netflow/2.6/build/make.log for more information.
> dpkg: error processing package iptables-netflow-dkms (--configure):
> installed iptables-netflow-dkms package post-installation script
> subprocess returned error exit status 10
This is probably because of some backported fixes to kernel security
updates in bullseye which ipt_NETFLOW upstream didn't expect to
already see in that seemingly older kernel version. Happened in the
past and will likely happen again over time. :-/
Generally I see two ways to fix this, with both having pros and cons:
* Restrict module to kernel ≥ 6.1. Disadvantage: Will refuse to work
with older, locally compiled kernels even if it would work.
Advantage: Will still work for late upgrades even if the Bullseye
kernel gets another backported fix which then will make the upgrade
fail in the same way again.
* Fix the build by probably updating versions in some of the #ifdefs
in the code which try to decide on the right kernel API.
Advantage: Will also work for those who need older kernels (even if
only for a while).
Disadvantage: Might break again on future backported kernel fixes in
Bullseye.
> As during the upgrade phase it is very likely that both the old and new
> kernel and their headers are installed, the dkms module should be able
> to build for both kernel versions (or use some BUILD_EXCLUSIVE_*
> settings to exclude unsupported versions,
BUILD_EXCLUSIVE_* would be my currently slightly preferred approach as
it's likely much simpler to implement and its impact is more clear,
but not necessarily "smaller". Currently trying to figure out how it
actually works.
> this will be easier from bookworm+1 onwards).
Ok. Well, I'll see.
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function 'nf_seq_show':
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:39: warning: format
> '%lu' expects argument of type 'long unsigned int', but argument 3 has type
> 's64' {aka 'long long int'} [-Wformat=]
> 762 | seq_printf(seq, " Flows selected %lu, discarded %lu.",
> | ~~^
> | |
> | long unsigned int
> | %llu
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:54: warning: format
> '%lu' expects argument of type 'long unsigned int', but argument 4 has type
> 's64' {aka 'long long int'} [-Wformat=]
> 762 | seq_printf(seq, " Flows selected %lu, discarded %lu.",
> | ~~^
> | |
> | long unsigned int
> | %llu
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:766:39: warning: format
> '%lu' expects argument of type 'long unsigned int', but argument 3 has type
> 's64' {aka 'long long int'} [-Wformat=]
> 766 | seq_printf(seq, " Flows selected %lu.",
> atomic64_read(&flows_selected));
> | ~~^
> | |
> | long unsigned int
> | %llu
At least these warnings look familiar. I think I also saw them when I
tried to compile it against kernel 6.3.1 in experimental (which also
failed).
Anyway, working on it now. Not yet sure which way I'll go, but
restricting it to only Bookworm's kernel (or newer) seems to be the
safest way to reduce the amount of fallout with older kernels as well
as the probably easier way.
(I deliberately didn't write "with less impact" as the impact IMHO
isn't comparable that well: It either _immediately_ affects quite a
large set of non-bookworm kernels, or it _may_ affect some future
kernels at some point in the future and _might_ cause a very similar
issue for late upgraders again. Not sure if any of that makes any of
the two solutions "the better one", but I have a slight preference to
the variant with the quite clear impact.)
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
