April 2022 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[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