January 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 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 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 1188957] New: Micro OS Desktop GNOME: Mesa-dri-nouveau not installed on first boot
by bugzilla_noreply＠suse.com 29 Mar '22

29 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1188957 Bug ID: 1188957 Summary: Micro OS Desktop GNOME: Mesa-dri-nouveau not installed on first boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: richwallwork(a)pm.me QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I've installed MicroOS desktop GNOME and noticed that it was reporting that the built in Intel gfx is the graphics adapter rather than the installed Nvidia card (which works fine on regular Tumbleweed). the Journal suggests that nouveau_dri.so cannot be found in /usr/lib64/dri and it seems the Mesa-dri-nouveau package wasn't installed. I used: sudo tukit --continue execute bash zypper in Mesa-dri-nouveau and after a reboot the system is working fine with nouveau. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1194997] New: Kubic/MicroOS libvirt Vagrant instances can not run
by bugzilla_noreply＠suse.com 02 Mar '22

02 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1194997 Bug ID: 1194997 Summary: Kubic/MicroOS libvirt Vagrant instances can not run Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: jason.evans(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- # How to reproduce the issue: On Tumbleweed, install vagrant and vagrant-libvirt, and all of the associated dependencies. # Initialize Vagrant vagrant init opensuse/Kubic.x86_64 # Update the Vagrantfile to include the following lines: config.vm.synced_folder ".", "/vagrant", disabled: true config.vm.synced_folder ".", "/opt/vagrant" # Start the VM vagrant up # VM errors out due to NFS issues. ... ==> default: Exporting NFS shared folders... ==> default: Preparing to edit /etc/exports. Administrator privileges will be required... ==> default: Mounting NFS shared folders... ==> default: Pruning invalid NFS exports. Administrator privileges will be required... ==> default: Removing domain... ==> default: Deleting the machine folder The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! mount -o vers=3,udp 192.168.121.1:/home/tux/temp/newtest /opt/vagrant Stdout from the command: Stderr from the command: mount.nfs: requested NFS version or transport protocol is not supported Go Back -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1193706] New: pkcon reporting a (spurious?) read-only fs error
by bugzilla_noreply＠suse.com 25 Feb '22

25 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1193706 Bug ID: 1193706 Summary: pkcon reporting a (spurious?) read-only fs error 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: dfaggioli(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hey! So, since some users were complaining about pkcon throwing errors on MicroOS, I decided to try myself (I just installed snapshot 20211211). It is, in fact, the case that the following shows up: dario@localhost:~> pkcon install rclone Fatal error: Failed to create directory "/.snapshots/4/snapshot/etc/dnf/modules.d": 30 - Read-only file system However, if I try again, it seems the package was installed inside of the snapshot: dario@localhost:~> pkcon -v install rclone 22:33:59 PackageKit Verbose debugging enabled (on console 1) 22:34:00 PackageKit role now resolve PackageKit adding state 0x559f4fd43be0 PackageKit notify::connected PackageKit remove state 0x559f4fd43be0 Fatal error: rclone-1.57.0-1.1.x86_64 is already installed And if I reboot, rclone is there: dario@localhost:~> rclone -h Rclone syncs files to and from cloud storage providers as well as mounting them, listing them in lots of different ways. See the home page (https://rclone.org/) for installation, usage, documentation, changelog and configuration walkthroughs. Usage: rclone [flags] rclone [command] ... ... ... So, is that "Fatal error" just some spurious message we should suppress? Or has something really gone bad, despite the package ending up being installed (from what I can tell) correctly? Neal, any idea? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1183856] New: fstab gets overriden by transactional-update
by bugzilla_noreply＠suse.com 18 Feb '22

18 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1183856 Bug ID: 1183856 Summary: fstab gets overriden by transactional-update 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: nmoreychaisemartin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Running transactional-update removes fstab entries that were added post install Steps to reproduce: - Add fstab entry using transactional-update -c shell - Reboot [ fstab is properly updated ] - Run transactional-update pkg in something - cat /var/lib/overlay/<last overlay>/etc/fstab (or reboot and check fstab) fstab entry is now missing -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1183521] New: [Build 20210312] openQA test fails in transactional_update
by bugzilla_noreply＠suse.com 18 Feb '22

18 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1183521 Bug ID: 1183521 Summary: [Build 20210312] openQA test fails in transactional_update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1666862/modules/tran sactional_update/steps/81 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: iforster(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: openQA Blocker: Yes Two bugs were observed when running the latest transactional-update on an older Tumbleweed snapshot: 1. "transactional-update" fails in zypper, because /var/lib/rpm inside the new root is an absolute symlink pointing to the current /, which is read-only 2. transactional-update 3.20.0 creates snapshots which transactional-update 2.24.1 does not understand due to a different workdir= value in /etc/fstab ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-ContainerHost-x86_64-container-host-old2microosnext@64bit fails in [transactional_update](https://openqa.opensuse.org/tests/1666862/modules/tra… ## Test suite description Boot from existing, static MicroOS ContainerHost image and transactional-update dup to snapshot under test. ## Reproducible Fails since (at least) Build [20210223](https://openqa.opensuse.org/tests/1644898) ## Expected result Last good: [20210222](https://openqa.opensuse.org/tests/1642729) (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 on the CC list for the bug.

1 4

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

24 Jan '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 https://bugzilla.suse.com/show_bug.cgi?id=1186158#c7 --- Comment #7 from G.M. Venekamp <gm.venekamp(a)quicknet.nl> --- The use case that I have and think others might as well is the following: I'd like to run my containers with as little privileges as possible. This is for security reasons. Therefore I run my containers as an ordinary user and not as root. Podman has decent support for this. In order to support multiple containers I'd like to use a proxy. My choice is traefik. Since I run my containers as an unprivileged user I must run traefik as the same user, because of namespaces. One feature of traefik is dynamic configuration of containers and it needs access to /var/run/podman/podman.sock Now, security wise you probabely don't want to give traefik direct access to that socket. You put something inbetween that restricts traefik's access, i.e. read only to subset of the API. However, this proxy would require the same level of access to the socket. In short: traefik could use the podman.sock to learn about running containers. However, because container running as an unprivileged user rerequire traefik to be run as the same unprivileged user it must be able to access podman.sock as the unprivileged user. One thing to note though is that if I would have another privileged user, that user will not be able to access the namespaces of the other unprivileged user. Just like root and non-root users cannot use each other namespaces, unprivileged user cannot use them amongst themselve as well. If you run containers as an unprivileged user, and you run as root: podman container ls, you will see container created as root and not any containers owned by other users. -- 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 24 Jan '22

24 Jan '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 https://bugzilla.suse.com/show_bug.cgi?id=1186158#c6 Gayane Osipyan <gayane.osipyan(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gayane.osipyan(a)suse.com --- Comment #6 from Gayane Osipyan <gayane.osipyan(a)suse.com> --- Hi, I am trying reproduce this can you please give more information why we want to reach podman.sock and also if possible more details about a container. By default it is not allowed and we would have to have either privilege container or container without SELinux protection. -- You are receiving this mail because: You are the assignee for the bug.

1 0