March 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 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

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

31 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c26 --- Comment #26 from Dirk Datzert <dirk.datzert(a)gmx.de> --- I also deploy a fresh VM and the weave/coredns is working fine again -- 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 31 Mar '22

31 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1197490 https://bugzilla.suse.com/show_bug.cgi?id=1197490#c25 --- Comment #25 from Robert Munteanu <rombert(a)apache.org> --- I ran a full test again, with a fresh VM. The problem seems fixed for me. I used registry.opensuse.org/home/favogt/boo1197490/container/kubic/weave-kube:2.8… for my tests, selected by checking the build logs from https://build.opensuse.org/package/show/home:favogt:boo1197490/kubic-weave-…. VM details: $ cat /etc/os-release NAME="openSUSE MicroOS" # VERSION="20220330" ID="opensuse-microos" ID_LIKE="suse opensuse opensuse-tumbleweed" VERSION_ID="20220330" PRETTY_NAME="openSUSE MicroOS" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:microos:20220330" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:MicroOS" LOGO="distributor-logo-MicroOS I ran the usual kubeadm setup commands $ kubeadm init $ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config And then overrode the weave patch as follows $ cp /usr/share/k8s-yaml/weave/weave.yaml weave.yaml $ cat >> kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization images: - name: registry.opensuse.org/kubic/weave-kube newName: registry.opensuse.org/home/favogt/boo1197490/container/kubic/weave-kube newTag: 2.8.1-21.16 resources: - weave.yaml # optional, for checking the manifests - kubectl build . $ kubectl apply -k . Everything works fine from a networking POV: $ kubectl get pod -A -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system coredns-fc8b57f45-r7kc2 1/1 Running 0 11m 10.32.0.3 kubic-0 <none> <none> kube-system coredns-fc8b57f45-wmshw 1/1 Running 0 11m 10.32.0.2 kubic-0 <none> <none> kube-system etcd-kubic-0 1/1 Running 0 11m 10.16.0.208 kubic-0 <none> <none> kube-system kube-apiserver-kubic-0 1/1 Running 0 11m 10.16.0.208 kubic-0 <none> <none> kube-system kube-controller-manager-kubic-0 1/1 Running 0 11m 10.16.0.208 kubic-0 <none> <none> kube-system kube-proxy-rrhkb 1/1 Running 0 11m 10.16.0.208 kubic-0 <none> <none> kube-system kube-scheduler-kubic-0 1/1 Running 0 11m 10.16.0.208 kubic-0 <none> <none> kube-system weave-net-wg4hq 2/2 Running 1 (4m14s ago) 4m16s 10.16.0.208 kubic-0 <none> <none> The warnings about failing to load modules are still there, but they don't seem to matter: $ kubectl -n kube-system logs daemonset/weave-net -c weave-init modprobe: can't load module nfnetlink (kernel/net/netfilter/nfnetlink.ko.zst): invalid module format Ignore the error if "xt_set" is built-in in the kernel In case it matters, I am creating the VMs using a patched version of https://github.com/kubic-project/kubic-terraform-kvm/ . -- 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 31 Mar '22

31 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 https://bugzilla.suse.com/show_bug.cgi?id=1186158#c9 --- Comment #9 from Gayane Osipyan <gayane.osipyan(a)suse.com> --- Hi, Sorry for delayed reply. I did following steps on my setup started podman as non root. systemctl --user start podman.service and then created traefik podman run -d --restart=always -p 8080:8080 -p 80:80 -p 444:443 -v ${traefik-dir}/:/etc/traefik/ -v /run/user/<uid>/podman/podman.sock:/run/user/<uid>/podman/podman.sock -v ${traefik-dir}/traefik.log:/traefik.log --name traefik traefik with selinux enabled I am able to access dashboard Also for debugging for me i find helpful to use setenforce 0 and look for denials with ausearch -m avc -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1197490] New: Kubic 20220322 fails to set up CNI with weave
by bugzilla_noreply＠suse.com 31 Mar '22

31 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1197490 Bug ID: 1197490 Summary: Kubic 20220322 fails to set up CNI with weave 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: rombert(a)apache.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have set up a set of libvirt VMs via https://github.com/kubic-project/kubic-terraform-kvm. I have initialised the control plane via kubeadm following the guide from https://en.opensuse.org/Kubic:kubeadm: kubeadm init --kubernetes-version=v1.23.4 # due to bug #1197489 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config kubectl apply -f /usr/share/k8s-yaml/weave/weave.yaml At this point the pod network should be available, but instead I get $ kubectl get pod -A -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system coredns-fc8b57f45-kfsv6 0/1 CrashLoopBackOff 6 (88s ago) 5m37s <none> kubic-0 <none> <none> kube-system coredns-fc8b57f45-nv4x9 0/1 CrashLoopBackOff 6 (81s ago) 5m37s <none> kubic-0 <none> <none> kube-system etcd-kubic-0 1/1 Running 0 5m34s 10.16.0.170 kubic-0 <none> <none> kube-system kube-apiserver-kubic-0 1/1 Running 0 5m34s 10.16.0.170 kubic-0 <none> <none> kube-system kube-controller-manager-kubic-0 1/1 Running 0 5m34s 10.16.0.170 kubic-0 <none> <none> kube-system kube-proxy-hx8mx 1/1 Running 0 5m38s 10.16.0.170 kubic-0 <none> <none> kube-system kube-scheduler-kubic-0 1/1 Running 0 5m34s 10.16.0.170 kubic-0 <none> <none> kube-system weave-net-2t4lz 2/2 Running 1 (4m51s ago) 4m57s 10.16.0.170 kubic-0 <none> <none> This is presumably due to an error loading the modules $ kubectl -n kube-system logs weave-net-2t4lz -c weave-init modprobe: can't load module nfnetlink (kernel/net/netfilter/nfnetlink.ko.zst): invalid module format Ignore the error if "xt_set" is built-in in the kernel I have loaded the modules required by weave and bumped the pods $ modprobe nfnetlink $ modprobe ip_set $ kubectl -n kube-system rollout restart daemonset weave-net daemonset.apps/weave-net restarted This time there are no more logs in weave-init $ kubectl -n kube-system logs weave-net-jks7b -c weave-init The weave status seems ok $ kubectl -n kube-system exec weave-net-jks7b -c weave -- /home/weave/weave --local status Version: 2.8.1 (failed to check latest version - see logs; next check at 2022/03/24 23:46:26) Service: router Protocol: weave 1..2 Name: be:f7:8c:d7:49:12(kubic-0) Encryption: disabled PeerDiscovery: enabled Targets: 0 Connections: 0 Peers: 1 TrustedSubnets: none Service: ipam Status: ready Range: 10.32.0.0/12 DefaultSubnet: 10.32.0.0/12 I restarted the CoreDNS pods to make sure that they get a chance to be restarted and allocated IPs. $ kubectl -n kube-system rollout restart deployment coredns deployment.apps/coredns restarted After the restart they enter a CrashLoopBackOff rather quickly kube-system coredns-7d9d9d5f9f-7cz4w 0/1 CrashLoopBackOff 2 (2s ago) 21s kube-system coredns-7d9d9d5f9f-2cgwd 0/1 CrashLoopBackOff 2 (1s ago) 22s -- You are receiving this mail because: You are the assignee for the bug.

1 15