April 2022 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[kubic-bugs] [Bug 1167780] New: MicroOS images don't update grub if booted without EFI
by bugzilla_noreply＠novell.com 09 Jan '23

09 Jan '23

http://bugzilla.suse.com/show_bug.cgi?id=1167780 Bug ID: 1167780 Summary: MicroOS images don't update grub if booted without EFI Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: fvogt(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: --- Blocker: --- The .qcow2 images are meant to work fine on systems with EFI (optionally secure boot) and without, so they have both i386-pc and x86_64-efi targets of grub2 installed by kiwi during image building. Kiwi sets LOADER_TYPE="grub2-efi" for this. When booting the image without EFI though, this is not changed by anything and so update-bootloader only manages the x86_64-efi target of grub2. As the grub.cfg file is in the same location, there aren't any immediate issues, but it means that grub is never updated in those deployments. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1195878] New: [Build 20220211] openQA test fails in disk_boot
by bugzilla_noreply＠suse.com 26 Oct '22

26 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1195878 Bug ID: 1195878 Summary: [Build 20220211] openQA test fails in disk_boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2186742/modules/disk _boot/steps/5 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-x86_64-microos@64bit fails in [disk_boot](https://openqa.opensuse.org/tests/2186742/modules/disk_boot/step… Feb 13 08:01:56.395743 localhost dracut-initqueue[502]: /sbin/ifup: line 135: dhclient: command not found ## Test suite description ## Reproducible Fails since (at least) Build [20220211](https://openqa.opensuse.org/tests/2186317) ## Expected result Last good: [20220210](https://openqa.opensuse.org/tests/2184227) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1183582] New: transactional server role has very inconsistent package selection (TW, SLE, Leap)
by bugzilla_noreply＠suse.com 10 Aug '22

10 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1183582 Bug ID: 1183582 Summary: transactional server role has very inconsistent package selection (TW, SLE, Leap) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Selecting the transactional server role results in a very different selection of patterns and packages. On Tumbleweed: https://openqa.opensuse.org/tests/1667896#step/disable_grub_timeout/13 Documentation, Minimal Base, Enhanced Base, AppArmor, YaST Base, Software Management, Minimal Appliance Base On SLE 15 SP3: https://openqa.suse.de/tests/5670408#step/disable_grub_timeout/14 Minimal Base, Enhanced Base, AppArmor, 32-Bit Runtime Environment On Leap 15.3: https://openqa.opensuse.org/tests/1667171#step/disable_grub_timeout/13 Minimal Base, Minimal Appliance Base -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1196547] New: MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 10 Aug '22

10 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1196547 Bug ID: 1196547 Summary: MicroOS Desktop GNOME system role doesn't preinstall language subpackages Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: fcrozat(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Follow-up of https://github.com/yast/skelcd-control-MicroOS/pull/51 Installing MicroOS Desktop (GNOME system role) doesn't install the language subpackages for the select language on the installer. Languages subpackages are currently handled as soft dependencies, which doesn't mix well with MicroOS relying only on requires. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1198946] kured and coredns pods unable to start due to possible weave-net issues[?] on upgraded nodes
by bugzilla_noreply＠suse.com 28 Apr '22

28 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198946 https://bugzilla.suse.com/show_bug.cgi?id=1198946#c2 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fvogt(a)suse.com Resolution|--- |DUPLICATE --- Comment #2 from Fabian Vogt <fvogt(a)suse.com> --- You have to delete the weave files from /opt/cni and restart the cluster. *** This bug has been marked as a duplicate of bug 1197490 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 28 Apr '22

28 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c33 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxdairy(a)gmail.com --- Comment #33 from Fabian Vogt <fvogt(a)suse.com> --- *** Bug 1198946 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1198946] New: kured and coredns pods unable to start due to possible weave-net issues[?] on upgraded nodes
by bugzilla_noreply＠suse.com 28 Apr '22

28 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198946 Bug ID: 1198946 Summary: kured and coredns pods unable to start due to possible weave-net issues[?] on upgraded nodes Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: linuxdairy(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36 Build Identifier: kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(9a9735cfe115e606f3a239770ca167e1cf9ec03dd4aee9e4f0389a35f86d2182): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" This looks related to... https://github.com/weaveworks/weave/issues/3936 Where it's possible the CNI version if no longer being returned, and an inappropriate version is being guessed. Reproducible: Always Steps to Reproduce: 1. transactional-update dup on admin node, reboot, kubeadm update apply v1.23.4 2. kubectl get pods -n kube-system # kured and coredns pods will no longer start on updated node 3. Actual Results: repeated on second admin node...now I have 2/3 unhappy nodes for these pods. removed kured temporarily, updated coredns deployment to 4 replicas to borrow into non-upgraded worker nodes kubectl describe on either pod shows these events and never starts... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled <unknown> Successfully assigned kube-system/coredns-786c7c77c5-hd5s5 to kubic-cl01-admin03 Warning FailedCreatePodSandBox 70s kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(67b41291a8e187a02c5081ed3274e46fa76291b02ffa04b1a91cda14509a7080): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" Warning FailedCreatePodSandBox 57s kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(b7af2bdf70a0fd94907393632db5872dd6cec24b776bb720589163d6acc2368e): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" Warning FailedCreatePodSandBox 44s kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(7b3896770118a07abc72f5d2f968b4a92e23b331904da3ccbc14f5470a278453): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" Warning FailedCreatePodSandBox 33s kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(835af599d7573e79039af5d4dd7a7f3352fa1129f997de2072d4c2530ac16d27): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" Warning FailedCreatePodSandBox 18s kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(83f6b1a6b896001b5e255ee1b7c2d66953d11611ae3265f0cd5d6a1bf614d576): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" Warning FailedCreatePodSandBox 6s kubelet, kubic-cl01-admin03 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-786c7c77c5-hd5s5_kube-system_f4bf99e9-de85-4ccd-b47a-11b4e09defc3_0(9a9735cfe115e606f3a239770ca167e1cf9ec03dd4aee9e4f0389a35f86d2182): error adding pod kube-system_coredns-786c7c77c5-hd5s5 to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" Expected Results: coredns and kured pods should start. coredns is a little important to a kubernetes cluster. kured is nice to have. I went with critical for severity. No coredns will be bad...and my upgrade of 13 nodes is stuck in the middle. I could possibly reboot and go back, except the 1.23.0 images for x86_64 of kube-apiserver, etc. are no longer accessible on registry.opensuse.org leading to image pull issues. cni-1.0.1-1.1.x86_64 cni-plugins-1.1.1-1.1.x86_64 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1175850] User mount option 'x-initrd.mount' vanishes during initrd transitions
by bugzilla_noreply＠suse.com 21 Apr '22

21 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1175850 Franck Bui <fbui(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1198731 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175850] User mount option 'x-initrd.mount' vanishes during initrd transitions
by bugzilla_noreply＠suse.com 21 Apr '22

21 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c21 --- Comment #21 from Franck Bui <fbui(a)suse.com> --- So there're actually 2 problems (at least) that need to be solved: - systemd doesn't rely on libmount when switching to the new root hence libmount is not aware that the mounted tree at '/sysroot' has been moved to '/' and therefore /run/mount/utab isn't updated accordingly. This issue is tracked by https://github.com/systemd/systemd/issues/15266 /upstream side) and by this bsc (SUSE side). - even if libmount was notified, it currently doesn't update entries in utab for any sub mounts below '/sysroot'. This issue is tracked by https://github.com/util-linux/util-linux/issues/1659 and by bsc#1198731. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175850] User mount option 'x-initrd.mount' vanishes during initrd transitions
by bugzilla_noreply＠suse.com 21 Apr '22

21 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1175850 Franck Bui <fbui(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|MicroOS Desktop can't |User mount option |reboot? |'x-initrd.mount' vanishes | |during initrd transitions -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198653] New: [MicroOS Desktop] - Appimage won't execute, fusermount not found
by bugzilla_noreply＠suse.com 20 Apr '22

20 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198653 Bug ID: 1198653 Summary: [MicroOS Desktop] - Appimage won't execute, fusermount not found Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: fenyx(a)vivaldi.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, I recently started experimenting with MicroOS as a desktop. One of the first problems I encountered was that several of my Appimages would not run due a FUSE issue. To Reproduce: 1. Fresh install of MicroOS (for mine, I used the Gnome Desktop) 2. Download the Bitwarden Appimage -> https://vault.bitwarden.com/download/?app=desktop&platform=linux 3. Attempt to launch, the following error will be produced ``` :~> ./Bitwarden-1.32.1-x86_64.AppImage fuse: failed to exec fusermount: No such file or directory Cannot mount AppImage, please check your FUSE setup. You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option. See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information open dir error: No such file or directory ``` Fuse is installed in base MicroOS, it looks like this an issue that can be resolved with a symlink since /usr/bin/fusermount3 exists and there is no /usr/bin/fusermount. I confirmed this solution works by running ``` sudo tukit execute bash ln -s /usr/bin/fusermount3 /usr/bin/fusermount exit systemctl reboot ``` This issue also exists when running the Nextcloud Appimage (https://github.com/nextcloud/desktop/releases/download/v3.4.4/Nextcloud-3.4…) While this may be a minor usability issue, this is one of the papercuts I encountered using MicroOS as a Desktop. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c32 Robert Munteanu <rombert(a)apache.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(rombert(a)apache.or | |g) | --- Comment #32 from Robert Munteanu <rombert(a)apache.org> --- (In reply to Fabian Vogt from comment #31) > (In reply to Robert Munteanu from comment #30) > > (In reply to Fabian Vogt from comment #29) > > > That looks like the used CNI plugin is still the old broken one. Did the > > > weave-init container run and replace it? > > > > I am not sure about replacing it. Initially the output from the weave-init > > container is > > > > modprobe: can't load module ip_set > > (kernel/net/netfilter/ipset/ip_set.ko.zst): invalid module format > > Ignore the error if "xt_set" is built-in in the kernel > > > > I restarted all pods in the weave daemonset, but that did not help. There is > > no more output from the weave-init container, but the containers are still > > stuck in the ContainerCreating status. > > FWICT, weave-init does > > if [ ! -f "$1/$CNI_PLUGIN_NAME" ]; then > cp /usr/bin/weaveutil "$1/$CNI_PLUGIN_NAME" > fi > > so it doesn't overwrite an existing cni plugin. You can try rm > /opt/cni/bin/weave* and restarting weave-init. That was it, thanks! After performing this operation on all nodes the workloads are slowly recovering. This explains why a new installation worked out of the box, but an upgraded cluster did not work. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c31 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rombert(a)apache.or | |g) --- Comment #31 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Robert Munteanu from comment #30) > (In reply to Fabian Vogt from comment #29) > > That looks like the used CNI plugin is still the old broken one. Did the > > weave-init container run and replace it? > > I am not sure about replacing it. Initially the output from the weave-init > container is > > modprobe: can't load module ip_set > (kernel/net/netfilter/ipset/ip_set.ko.zst): invalid module format > Ignore the error if "xt_set" is built-in in the kernel > > I restarted all pods in the weave daemonset, but that did not help. There is > no more output from the weave-init container, but the containers are still > stuck in the ContainerCreating status. FWICT, weave-init does if [ ! -f "$1/$CNI_PLUGIN_NAME" ]; then cp /usr/bin/weaveutil "$1/$CNI_PLUGIN_NAME" fi so it doesn't overwrite an existing cni plugin. You can try rm /opt/cni/bin/weave* and restarting weave-init. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c30 Robert Munteanu <rombert(a)apache.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(rombert(a)apache.or | |g) | --- Comment #30 from Robert Munteanu <rombert(a)apache.org> --- (In reply to Fabian Vogt from comment #29) > That looks like the used CNI plugin is still the old broken one. Did the > weave-init container run and replace it? I am not sure about replacing it. Initially the output from the weave-init container is modprobe: can't load module ip_set (kernel/net/netfilter/ipset/ip_set.ko.zst): invalid module format Ignore the error if "xt_set" is built-in in the kernel I restarted all pods in the weave daemonset, but that did not help. There is no more output from the weave-init container, but the containers are still stuck in the ContainerCreating status. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c29 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rombert(a)apache.or | |g) --- Comment #29 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Robert Munteanu from comment #28) > (In reply to Fabian Vogt from comment #27) > > openQA agrees that weave is fixed: > > https://openqa.opensuse.org/tests/2282201#step/kubead > > Something is still wrong with my Kubic cluster. I upgraded the control plane > + workers to 20220405 , and the pods still fail to create. This time the > message is > > Warning FailedCreatePodSandBox 16m kubelet Failed to > create pod sandbox: rpc error: code = Unknown desc = failed to create pod > network sandbox > k8s_promtail-sfljk_lmn-system_4828843e-a491-4ee6-bce5- > 6a256f2c65cb_0(c14e6bd431ff06ab322887c4b7b17e7cc9c0ea5d39e16a56ee3e5192422511 > 93): error adding pod lmn-system_promtail-sfljk to CNI network "weave": > plugin type="portmap" failed (add): failed to parse config: could not parse > prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 > 0.4.0] but unmarshalled CNIVersion is "0.1.0" > > I am not sure where that is coming from; /etc/cni/net.d/10-weave.conflist > looks ok in terms of versions: > > { > "cniVersion": "0.3.0", > "name": "weave", > "plugins": [ > { > "name": "weave", > "type": "weave-net", > "hairpinMode": true > }, > { > "type": "portmap", > "capabilities": {"portMappings": true}, > "snat": true > } > ] > } > > I checked and the image that I have locally seems fine: > > $ crictl pull registry.opensuse.org/kubic/weave-kube:2.8.1 > Image is up to date for > registry.opensuse.org/kubic/weave-kube@sha256: > 61b541bb0b05ddf8f58e73fb5e53b6a9a44b6c26bda5edc3719f8445f1acb7e0 > > Do you have any idea about what is going wrong here? That looks like the used CNI plugin is still the old broken one. Did the weave-init container run and replace it? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c28 --- Comment #28 from Robert Munteanu <rombert(a)apache.org> --- (In reply to Fabian Vogt from comment #27) > openQA agrees that weave is fixed: > https://openqa.opensuse.org/tests/2282201#step/kubead Something is still wrong with my Kubic cluster. I upgraded the control plane + workers to 20220405 , and the pods still fail to create. This time the message is Warning FailedCreatePodSandBox 16m kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_promtail-sfljk_lmn-system_4828843e-a491-4ee6-bce5-6a256f2c65cb_0(c14e6bd431ff06ab322887c4b7b17e7cc9c0ea5d39e16a56ee3e519242251193): error adding pod lmn-system_promtail-sfljk to CNI network "weave": plugin type="portmap" failed (add): failed to parse config: could not parse prevResult: could not parse prevResult: result type supports [0.3.0 0.3.1 0.4.0] but unmarshalled CNIVersion is "0.1.0" I am not sure where that is coming from; /etc/cni/net.d/10-weave.conflist looks ok in terms of versions: { "cniVersion": "0.3.0", "name": "weave", "plugins": [ { "name": "weave", "type": "weave-net", "hairpinMode": true }, { "type": "portmap", "capabilities": {"portMappings": true}, "snat": true } ] } I checked and the image that I have locally seems fine: $ crictl pull registry.opensuse.org/kubic/weave-kube:2.8.1 Image is up to date for registry.opensuse.org/kubic/weave-kube@sha256:61b541bb0b05ddf8f58e73fb5e53b… Do you have any idea about what is going wrong here? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1186158] SElinux is blocking podman socket access to /var/run/podman/podman.sock
by bugzilla_noreply＠suse.com 06 Apr '22

06 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 https://bugzilla.suse.com/show_bug.cgi?id=1186158#c12 --- Comment #12 from Gayane Osipyan <gayane.osipyan(a)suse.com> --- Hi, Thanks for details after doing some research and also replicating this issue on non microos setup with SElinux enabled my understanding is following 1. File provider should be used for rootless podman container+traefik .(For my testing purposes it worked) providers: file: filename: /path/to/config/dynamic_conf.yml 2. SElinux policy can be adjusted locally but seems its strongly not recommended(you can use udica which will generate policy for specific container) 3. run Traefik from a rootfull container. One suggestion I found is to run traefik non-rootfull and use the tcp exposed docker-socket .The dockerproxy has to run rootfull .(Haven't tested this ) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 06 Apr '22

06 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c27 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #27 from Fabian Vogt <fvogt(a)suse.com> --- openQA agrees that weave is fixed: https://openqa.opensuse.org/tests/2282201#step/kubeadm/16 @dirk: Looks like your issue is something else, something more specific to your setup. I'm not sure how to interpret the logs, but it could be that coredns isn't responding. The readiness probe failure is more recent than the weave related FailedCreatePodSandBox, so it looks like the network setup went past the original point of failure. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1186158] New: SElinux is blocking socket access for podman
by bugzilla_noreply＠suse.com 04 Apr '22

04 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 Bug ID: 1186158 Summary: SElinux is blocking socket access for podman Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE MicroOS Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: gm.venekamp(a)quicknet.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- test-vm:~ # head -2 /etc/os-release NAME="openSUSE MicroOS" # VERSION="20210515" When starting a container (as root) like traefik, I get the following error: test-vm:~ # podman run -p 8080:8080 -p 80:80 -v /etc/traefik/traefik.yml:/etc/traefik/traefik.yml -v /var/run/podman/podman.sock:/var/run/docker.sock traefik:v2.0 time="2021-05-18T06:46:37Z" level=info msg="Configuration loaded from file: /etc/traefik/traefik.yml" time="2021-05-18T06:46:38Z" level=error msg="Failed to retrieve information of the docker client and server host: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/version: dial unix /var/run/docker.sock: connect: permission denied" providerName=docker This is what /var/log/audit/audit/log tells me: type=AVC msg=audit(1621319586.484:965): avc: denied { connectto } for pid=1785 comm="traefik" path="/run/podman/podman.sock" scontext=system_u:system_r:container_t:s0:c741,c830 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=1 test-vm:~ # ll -Z /var/run/podman/podman.sock srw-rw----. 1 root root system_u:object_r:var_run_t:s0 0 May 18 08:46 /var/run/podman/podman.sock Am I doing anything wrong -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1197897] New: Podman/Toolbox unable to run rootless/user containers
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1197897 Bug ID: 1197897 Summary: Podman/Toolbox unable to run rootless/user containers Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Snapshot 20220330 seems to have introduced something that's broken user containers on MicroOS It's not SELinux (setenforce 0 doesn't change the symptoms) toolbox -u or podman run hello-world as a user fails with the following error Error: OCI runtime error: runc create failed: unable to start container process: can't get final child's PID from pipe: EOF I can't see any obvious changes to runc/podman that could obviously explain it..any suggestions on where to look next? It didn't occur in Snapshot 20220324..so I'm rolling back to that for now -- You are receiving this mail because: You are the assignee for the bug.

1 1