[Bug 1106751] New: iptables does not work with kernel-default-base
http://bugzilla.suse.com/show_bug.cgi?id=1106751 Bug ID: 1106751 Summary: iptables does not work with kernel-default-base Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: fvogt@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Initially reported as https://github.com/kubic-project/automation/pull/474#issuecomment-417329301 Docker (and cri-o) do not work in Kubic VM images as iptables does not work: g47:~ # iptables -L iptables: No chain/target/match by that name. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Fabian Vogt
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c1
Fabian Vogt
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c2
--- Comment #2 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Michal Kubeček
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c3
Fabian Vogt
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c4
--- Comment #4 from Fabian Vogt
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c5
--- Comment #5 from Kristyna Streitova
@kstreitova: This was actually handled wrongly in iptables itself, a missing memset(&info, 0, sizeof(info)); in libiptc.c caused it to read garbage. It would be nice to have that fixed as well, even if it's ultimately a kernel bug.
Could you be a little bit more specific, please? Or even better, can you provide a patch if you've already identified where the problem lies? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c6
--- Comment #6 from Fabian Vogt
(In reply to Fabian Vogt from comment #1)
@kstreitova: This was actually handled wrongly in iptables itself, a missing memset(&info, 0, sizeof(info)); in libiptc.c caused it to read garbage. It would be nice to have that fixed as well, even if it's ultimately a kernel bug.
Could you be a little bit more specific, please? Or even better, can you provide a patch if you've already identified where the problem lies? Thanks!
Sure: diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c index a6e70571..8c03ab42 100644 --- a/libiptc/libiptc.c +++ b/libiptc/libiptc.c @@ -1303,6 +1303,7 @@ TC_INIT(const char *tablename) { struct xtc_handle *h; STRUCT_GETINFO info; + memset(&info, 0, sizeof(info)); unsigned int tmp; socklen_t s; int sockfd; Without this, iptables -L reads garbage from the struct as the kernel never filled it in the bugged case, leading to weird issues like mmapping a few TiB of memory. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c7
Fabian Vogt
Looks like the bug is back - kernel-default-base in TW is missing bpfilter again.
Additionally, the split of kernel-source and kernel-default-base means that TW does currently not rebuild kernel-default-base at all. This means that kernel-default is at 5.0.5 while kernel-default-base remains at 5.0.3 indefinitely.
@msuchanek: Do you plan to revert the split in master/stable as well soon? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c8
--- Comment #8 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c9
Fabian Vogt
Don't we have some OBS setup instead? Putting back to kernel-source is a step back, make the whole effort useless.
FWIW, the same problem is applied to a package like perf. We need a general solution in OBS.
I can only think of a hacky way to (ab)use the rebuild bot: Add a fake "-rebuildme" subpackage to kernel-default-base.spec which has %(rpm -q --qf 'Requires: %{name} = %{version}-%{release}\n' kernel-default). As the subpackage turns uninstallable once kernel-default changed, it would be rebuilt. @dimstar, @lnussel: Any better idea? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c10
Dominique Leuenberger
I can only think of a hacky way to (ab)use the rebuild bot: Add a fake "-rebuildme" subpackage to kernel-default-base.spec which has %(rpm -q --qf 'Requires: %{name} = %{version}-%{release}\n' kernel-default).
As the subpackage turns uninstallable once kernel-default changed, it would be rebuilt.
@dimstar, @lnussel: Any better idea?
Yucks - let alone this can't work (ignoring the non-escaped %{version} for now): The release counter is not under control on kernel-default-base: it is - and will remain for a while, at 1.x, until it gets direct source changes, when it turns into 2.x - and actually, weirdly, now it is 1.2.1.6... WTH) So having a requires on a kernel version-release would only make it rebuild forever in an attempt to reach the checking/rebuild counter of kernel-default If anything, we'd need to add it to the parent/child rebuild trigger, as in: https://github.com/openSUSE/openSUSE-release-tools/blob/master/rebuildpacs.p... But that is also 'just' a workaround - OBS itself has no support for this (except switching to rebuild=direct|transitive, which is too expensive for TW) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c11
--- Comment #11 from Petr Tesařík
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c12
--- Comment #12 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c13
--- Comment #13 from Fabian Vogt
(In reply to Fabian Vogt from comment #9)
I can only think of a hacky way to (ab)use the rebuild bot: Add a fake "-rebuildme" subpackage to kernel-default-base.spec which has %(rpm -q --qf 'Requires: %{name} = %{version}-%{release}\n' kernel-default).
As the subpackage turns uninstallable once kernel-default changed, it would be rebuilt.
@dimstar, @lnussel: Any better idea?
Yucks - let alone this can't work (ignoring the non-escaped %{version} for now):
The release counter is not under control on kernel-default-base: it is - and will remain for a while, at 1.x, until it gets direct source changes, when it turns into 2.x - and actually, weirdly, now it is 1.2.1.6... WTH)
The kernel version from git is part of the Release: field in the .spec.
So having a requires on a kernel version-release would only make it rebuild forever in an attempt to reach the checking/rebuild counter of kernel-default
It wouldn't - kernel-default-base.spec is separate from kernel-default.spec
If anything, we'd need to add it to the parent/child rebuild trigger, as in: https://github.com/openSUSE/openSUSE-release-tools/blob/master/rebuildpacs. pl#L77
Yes, that's cleaner.
But that is also 'just' a workaround - OBS itself has no support for this (except switching to rebuild=direct|transitive, which is too expensive for TW)
(In reply to Petr Tesařík from comment #11)
I must be missing something.
kernel-default-base now BuildRequires kernel-default-devel. Since this binary package is built from kernel-default, it must change whenever kernel-default is rebuilt, triggering a rebuild of kernel-default-base (because of meta change).
Why does it not happen for kernel-default-base?
TW does not have rebuild=transient/direct enabled, this is intentional.
(In reply to Ludwig Nussel from comment #12) well, if we wanted to rely on rebuildpacs.pl that can be done in a more easy way, it has a list of special packages built in. so just add yet another one :)
As long as kernel-default-base has bcntsynctag on kernel-source it should be rebuilt automatically with rebuild counter sync by OBS though.
That might work as well, but would require special configuration everywhere... The current design of a split kernel-default-base.spec has multiple issues: - Needs to be handled separately for maintenance submissions - Is missing debuginfo and debugsources - This rebuild issue -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c17
--- Comment #17 from Kristyna Streitova
diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c index a6e70571..8c03ab42 100644 --- a/libiptc/libiptc.c +++ b/libiptc/libiptc.c @@ -1303,6 +1303,7 @@ TC_INIT(const char *tablename) { struct xtc_handle *h; STRUCT_GETINFO info; + memset(&info, 0, sizeof(info)); unsigned int tmp; socklen_t s; int sockfd;
Without this, iptables -L reads garbage from the struct as the kernel never filled it in the bugged case, leading to weird issues like mmapping a few TiB of memory.
Thanks! I've submitted this patch to openSUSE:Factory via sr#691502. It was also reported upstream: https://bugzilla.netfilter.org/show_bug.cgi?id=1331 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c19
--- Comment #19 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c20
--- Comment #20 from Michal Suchanek
So having a requires on a kernel version-release would only make it rebuild forever in an attempt to reach the checking/rebuild counter of kernel-default
Why forever? Only until it's built against the current kernel.
If anything, we'd need to add it to the parent/child rebuild trigger, as in: https://github.com/openSUSE/openSUSE-release-tools/blob/master/rebuildpacs. pl#L77
This will not work. You are supposed to be able to build arbitrary subpackages, not just -base. (In reply to Fabian Vogt from comment #9)
I can only think of a hacky way to (ab)use the rebuild bot: Add a fake "-rebuildme" subpackage to kernel-default-base.spec which has %(rpm -q --qf 'Requires: %{name} = %{version}-%{release}\n' kernel-default).
As the subpackage turns uninstallable once kernel-default changed, it would be rebuilt.
I will add an empty subpackage and try rebuilding the kernel with it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c21
--- Comment #21 from Fabian Vogt
(In reply to Fabian Vogt from comment #9)
I can only think of a hacky way to (ab)use the rebuild bot: Add a fake "-rebuildme" subpackage to kernel-default-base.spec which has %(rpm -q --qf 'Requires: %{name} = %{version}-%{release}\n' kernel-default).
As the subpackage turns uninstallable once kernel-default changed, it would be rebuilt.
I will add an empty subpackage and try rebuilding the kernel with it.
Note that this will only have an effect inside openSUSE:Factory as that's what the bot is running against. So it can't really be tested, other than verifying that OBS says it's not installable. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c22
--- Comment #22 from Michal Suchanek
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c23
--- Comment #23 from Fabian Vogt
Can I run this bot against other repository?
The source is at https://github.com/openSUSE/openSUSE-release-tools/blob/master/rebuildpacs.p... I'm not sure whether it works against projects which don't contain an entire distro as it only looks for dependencies inside the project itself. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c29
--- Comment #29 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c32
--- Comment #32 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c34
--- Comment #34 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c35
--- Comment #35 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c36
--- Comment #36 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c37
--- Comment #37 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c38
--- Comment #38 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c43
--- Comment #43 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c44
--- Comment #44 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
http://bugzilla.suse.com/show_bug.cgi?id=1106751#c47
--- Comment #47 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1106751
Swamp Workflow Management
https://bugzilla.suse.com/show_bug.cgi?id=1106751
https://bugzilla.suse.com/show_bug.cgi?id=1106751#c54
Fabian Vogt
participants (2)
-
bugzilla_noreply@novell.com
-
bugzilla_noreply@suse.com