July 2021 - 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 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 1185461] New: ignition doesn't reset firstboot
by bugzilla_noreply＠suse.com 13 Dec '21

13 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1185461 Bug ID: 1185461 Summary: ignition doesn't reset firstboot 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Using openSUSE-MicroOS.x86_64-16.0.0-kvm-and-xen-Snapshot20210427.qcow2 in qemu with an ignition config that touches a file in /etc. Rebooting leads to maintenance mode as ignition started again and exists as the file already exist. So for some reason the no firstboot condition is not detected. /boot/writable/firstboot_happened exist though: Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report. Press Enter for maintenance (or press Control-D to continue): :/root# mount -o subvol=@/boot/writable /dev/vda3 /mnt :/root# ls /mnt/ firstboot_happened :/root# cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.11.16-1-default root=UUID=1bd1020f-74e9-4d1f-bb36-859e1f4e86bd rw rd.timeout=60 quiet systemd.show_status=yes console=ttyS0,115200 console=tty0 net.ifnames=0 ignition.firstboot ignition.platform.id=qemu -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1187313] New: selinux-policy-targeted breaks StandardOutput=tty
by bugzilla_noreply＠suse.com 02 Dec '21

02 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1187313 Bug ID: 1187313 Summary: selinux-policy-targeted breaks StandardOutput=tty Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: --- Blocker: --- Services with StandardOutput=tty (like MicroOS-Firstboot) fail to start when the targeted policy is enforced: Jun 11 13:57:05 f195.suse.de systemd[1183]: MicroOS-firstboot.service: Failed to set up standard input: Permission denied Jun 11 13:57:05 f195.suse.de kernel: audit: type=1400 audit(1623419825.264:7): avc: denied { watch watch_reads } for pid=1183 comm="(irstboot)" path="/dev/console" dev="devtmpfs" ino=12 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file permissive=0 Jun 11 13:57:05 f195.suse.de systemd[1183]: MicroOS-firstboot.service: Failed at step STDIN spawning /usr/libexec/MicroOS-firstboot: Permission denied The Fedora policy allows that for TTYs, so should probably do the same for console_device_t: https://github.com/fedora-selinux/selinux-policy/commit/f4a7e3a562499916c83… -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1188932] New: SELinux prevents systemd-firstboot
by bugzilla_noreply＠suse.com 29 Nov '21

29 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1188932 Bug ID: 1188932 Summary: SELinux prevents systemd-firstboot 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: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With active SELinux systemd-firstboot doesn't work: Fri 2021-07-30 13:54:16 UTC init.scope[1]: Starting First Boot Wizard... Fri 2021-07-30 13:54:16 UTC systemd-firstboot.service[560]: systemd-firstboot.service: Failed to set up standard input: Permission denied Fri 2021-07-30 13:54:16 UTC systemd-firstboot.service[560]: systemd-firstboot.service: Failed at step STDIN spawning systemd-firstboot: Permission denied Fri 2021-07-30 13:54:16 UTC init.scope[1]: systemd-firstboot.service: Main process exited, code=exited, status=208/STDIN Fri 2021-07-30 13:54:16 UTC init.scope[1]: systemd-firstboot.service: Failed with result 'exit-code'. Fri 2021-07-30 13:54:16 UTC init.scope[1]: Failed to start First Boot Wizard. Fri 2021-07-30 13:54:16 UTC kernel: audit: type=1400 audit(1627653256.048:3): avc: denied { watch watch_reads } for pid=560 comm="(irstboot)" path="/dev/console" dev="devtmpfs" ino=12 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file permissive=0 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[kubic-bugs] [Bug 1153687] New: Zypper repo name detection broken
by bugzilla_noreply＠novell.com 24 Nov '21

24 Nov '21

http://bugzilla.suse.com/show_bug.cgi?id=1153687 Bug ID: 1153687 Summary: Zypper repo name detection broken Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- zypper ar obs://some:where/ results in a URL such as https://download.opensuse.org/repositories/some:/where/openSUSE-MicroOS-201… -- You are receiving this mail because: You are the assignee for the bug.

2 16

[Bug 1188110] New: pkcon system-upgrade leads to unbootable system with kernel upgrade
by bugzilla_noreply＠suse.com 23 Nov '21

23 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188110 Bug ID: 1188110 Summary: pkcon system-upgrade leads to unbootable system with kernel upgrade Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: alois1(a)gmx-topmail.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I recently installed MicroOS Desktop KDE. I attempted to upgrade this system from 20210704 to 20210706 using pkcon, which included a kenel upgrade to 5.13. This upgrade lead to an unbootable system with the following symptoms: * In the GRUB menu, it is attempted to load the wrong kernel version (5.12.13). * When manually editing the kernel and initrd version to 5.13.0, the initrd enters emergency mode after some delay. * Further investigation shows that initrd is incomplete and lacks at least crypttab, so the partitions on the encrypted disks cannot be mounted and caused the timeout. The issue is reproducible, after rolling back to the last snapshot on 20210704 and attempting the upgrade again the symptoms are the same. I have for now upgraded the system using zypper dup inside tukit. This lead to a working upgraded system. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 1185647] New: GNOME Software not updating RPM packages
by bugzilla_noreply＠suse.com 12 Oct '21

12 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1185647 Bug ID: 1185647 Summary: GNOME Software not updating RPM packages 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: --- So, with Snapshot 20210427, pkcon now works for installing packages, e.g., from a terminal (although, it does follow weak dependencies, but that's another issue). However, updating via GNOME Software does not work yet. So, this is the situation right after install: dario@localhost:~> sudo snapper list # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ---+--------+-------+---------------------------------+------+------------+---------+-----------------------+-------------- 0 | single | | | root | | | current | 1* | single | | Wed 05 May 2021 07:17:32 AM UTC | root | 43.02 MiB | | first root filesystem | 2 | single | | Wed 05 May 2021 07:24:05 AM UTC | root | 36.47 MiB | number | after installation | important=yes In GNOME Software, I see the notification of some updates, I can go to the proper tab, click 'Download' and then click 'Restart & Install'. At which point, on the GUI, I see this error message: "Unable to install updates: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror-2dquark.Code1:Failed to create symlink: Read-only file system" If I go ahead, after the reboot, the updates have not been installed. This is the status of system snapshots: dario@localhost:~> sudo snapper list [sudo] password for root: # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ---+--------+-------+---------------------------------+------+------------+---------+-----------------------+------------------------------------- 0 | single | | | root | | | current | 1* | single | | Wed 05 May 2021 07:17:32 AM UTC | root | 144.00 KiB | | first root filesystem | 2 | single | | Wed 05 May 2021 07:24:05 AM UTC | root | 36.47 MiB | number | after installation | important=yes 3 | single | | Wed 05 May 2021 10:51:00 AM UTC | root | 19.75 MiB | | Snapshot Update of #1 | transactional-update-in-progress=yes 4 | single | | Wed 05 May 2021 10:55:47 AM UTC | root | 19.75 MiB | | Snapshot Update of #1 | transactional-update-in-progress=yes 5 | single | | Wed 05 May 2021 11:06:10 AM UTC | root | 19.75 MiB | | Snapshot Update of #1 | transactional-update-in-progress=yes 6 | single | | Wed 05 May 2021 11:06:48 AM UTC | root | 160.00 KiB | | Snapshot Update of #1 | transactional-update-in-progress=yes In journalctl, I see a bunch of lines like these: May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-.snapshots.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-boot-writable.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-root.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-sys-fs-fuse-connections.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-sys-kernel-config.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-sys-kernel-tracing.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: \x2esnapshots-6-snapshot-sys.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-proc.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-dev.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-kernel-config.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-kernel-tracing.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-kernel-debug.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-fs-selinux.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-fs-bpf.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-fs-pstore.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-fs-cgroup.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-kernel-security.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys-fs-fuse-connections.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy-sys.mount: Succeeded. May 05 11:07:19 localhost.localdomain systemd[1706]: tmp-transactional\x2dupdate\x2djNF9Qy.mount: Succeeded. PackageKit logs does not seem to me to contain anything related to this operation, but I'm happy to provide further info. After a few seconds, `snapper list` is slightly different (probably due to the fact that, right after boot, packagekit was scanning for updates): dario@localhost:~> sudo snapper list # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ---+--------+-------+---------------------------------+------+------------+---------+-----------------------+------------------------------------- 0 | single | | | root | | | current | 1* | single | | Wed 05 May 2021 07:17:32 AM UTC | root | 19.72 MiB | | first root filesystem | 2 | single | | Wed 05 May 2021 07:24:05 AM UTC | root | 36.47 MiB | number | after installation | important=yes 3 | single | | Wed 05 May 2021 10:51:00 AM UTC | root | 19.75 MiB | | Snapshot Update of #1 | transactional-update-in-progress=yes 4 | single | | Wed 05 May 2021 10:55:47 AM UTC | root | 19.75 MiB | | Snapshot Update of #1 | transactional-update-in-progress=yes 5 | single | | Wed 05 May 2021 11:06:10 AM UTC | root | 19.75 MiB | | Snapshot Update of #1 | transactional-update-in-progress=yes Of course, the expected results would be that packages are actually updated/installed. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[kubic-bugs] [Bug 1085619] New: Softlockup with btrfs and kubic (CaaSP on openSUSE)
by bugzilla_noreply＠novell.com 16 Sep '21

16 Sep '21

http://bugzilla.suse.com/show_bug.cgi?id=1085619 Bug ID: 1085619 Summary: Softlockup with btrfs and kubic (CaaSP on openSUSE) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kubic Assignee: jeffm(a)suse.com Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org, lpechacek(a)suse.com Found By: --- Blocker: --- With current openSUSE Kubic builds (CaaSP based on openSUSE Tumbleweed), we seem to run into the same issue as with CaaSP v1: bsc#1041296 - admin node freezes - no shell after putting password into login prompt Could it be that the fixes are missing in the upstream kernel? -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1188939] New: SELinux prevents podman from being run as a systemd service and from being updated
by bugzilla_noreply＠suse.com 30 Jul '21

30 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188939 Bug ID: 1188939 Summary: SELinux prevents podman from being run as a systemd service and from being updated Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: jonas.buettner(a)posteo.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since updating MicroOS to the snapshot 20210724 on my Raspberry Pi 4, running podman containers from a systemd service file fails. In audit.log the following is printed: type=AVC msg=audit(1627663525.962:2223): avc: denied { execute } for pid=11643 comm="(podman)" name="podman" dev="sda2" ino=125269 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 trawcon="system_u:object_r:container_runtime_exec_t:s0" The service file looks like this: [Unit] Description=Cups Container [Service] Restart=always ExecStart=/usr/bin/podman start -a cups ExecStop=/usr/bin/podman stop cups [Install] WantedBy=multi-user.target Running `podman start cups` directly from the CLI works. A potentially related issue is that updating to the newest snapshot fails while installing podman with the following error message: Installation of podman-3.2.3-1.1.aarch64 failed: Error: Subprocess failed. Error: RPM failed: error: lsetfilecon: (/usr/bin/podman;61042882, system_u:object_r:container_runtime_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed error: unpacking of archive failed on file /usr/bin/podman;61042882: cpio: (error 0x2) error: podman-3.2.3-1.1.aarch64: install failed error: podman-3.2.2-1.1.aarch64: erase skipped -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1149701] Ignition needs to autodetect the platform
by bugzilla_noreply＠suse.com 27 Jul '21

27 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1149701 http://bugzilla.opensuse.org/show_bug.cgi?id=1149701#c10 --- Comment #10 from Anthony Rabbito <hello(a)anthonyrabbito.com> --- Indeed I think it would be nice if the cloud team packaged and published Kubic as an official AMI. I've been in touch with cabelo who publishes a few OpenSUSE AWS AMI's and he said he'd take a look and getting kubic published. In the meantime and for what it's worth AWS image needs a little more then just changing the ignition.platform.id (https://build.opensuse.org/package/show/home:anthr76:kutara/kubic-images) I have yet to physically test these images yet but should get around to it this week. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1149701] Ignition needs to autodetect the platform
by bugzilla_noreply＠suse.com 27 Jul '21

27 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1149701 http://bugzilla.opensuse.org/show_bug.cgi?id=1149701#c9 --- Comment #9 from Ignaz Forster <iforster(a)suse.com> --- That's correct, Ignition itself does not provide any autodetection mechanism. The Cloud team is providing platform specific Cloud images for several of our SLE products including Ignition support. So wouldn't it make sense to also do so for our openSUSE distributions? If it really isn't an option to build Cloud provider specific images, then we may indeed think about splitting out the *ds-identify* binary from the cloud-init package and use it to detect the platform. From a quick look the only notable dependency seems to be *dmidecode*, which is present in the initrd already anyway for systemd-detect-virt, which is the current detection application (which detects VM and container technologies, but no cloud providers). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1149701] Ignition needs to autodetect the platform
by bugzilla_noreply＠suse.com 22 Jul '21

22 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1149701 http://bugzilla.opensuse.org/show_bug.cgi?id=1149701#c8 Anthony Rabbito <hello(a)anthonyrabbito.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #8 from Anthony Rabbito <hello(a)anthonyrabbito.com> --- AFAIK there's no way within ignition to detect the platform it's running on. FCOS builds multiple provider images. https://getfedora.org/en/coreos/download?tab=cloud_launchable&stream=stable -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1149701] Ignition needs to autodetect the platform
by bugzilla_noreply＠suse.com 22 Jul '21

22 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1149701 http://bugzilla.opensuse.org/show_bug.cgi?id=1149701#c7 Anthony Rabbito <hello(a)anthonyrabbito.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hello(a)anthonyrabbito.com --- Comment #7 from Anthony Rabbito <hello(a)anthonyrabbito.com> --- Is it possible to have this re-opened? I have a use-case for running Kubic in a few different cloud-environments and we need to have environments ignition.platform.id set. Ref - https://build.opensuse.org/request/show/907618?notification_id=27066471#com… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1187462] New: Snapshoot unusable (and "reverted") after updates, when SELinux enabled
by bugzilla_noreply＠suse.com 15 Jul '21

15 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187462 Bug ID: 1187462 Summary: Snapshoot unusable (and "reverted") after updates, when SELinux enabled 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: --- Hello, This is an intermittent issue that I am (and as far as I know also other MicroOS users) having. It appears that for triggering it, it is sufficient to use `transactional-udpate` or `tukit` directly (or `pkcon`, if on MicroOS desktop) for installing or updating some packages, or in general for modifying the system. During reboot, I quickly saw the error messages shown in screenshot_b.png. Then, during next boot, I see the messages shown in screenshot_a.png. The snapshot is then discarded and the system reboots fine, but of course without the modifications that were being attempted. Note that this does not reproduce 100% of the time. Also, when it reproduced, I always had SELinux enabled. That is, with SELinux enabled, it may or may not happen. With SELinux disabled, it never happens. At least that's my experience. Any idea? Or even anything I can do to help debugging? -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 1187219] New: virtlogd cannot read token due to SElinux
by bugzilla_noreply＠suse.com 12 Jul '21

12 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187219 Bug ID: 1187219 Summary: virtlogd cannot read token due to SElinux 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: gm.venekamp(a)quicknet.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This bug is might be related to: https://bugzilla.redhat.com/show_bug.cgi?id=1964317 virsh start <vm> gives a permission error on: /run/libvirt/common/system.token This is confirmed by: # systemctl status virtlogd.service �� virtlogd.service - Virtual machine log manager Loaded: loaded (/usr/lib/systemd/system/virtlogd.service; indirect; vendor preset: disabled) Active: active (running) since Wed 2021-06-09 03:31:21 CEST; 2 days ago TriggeredBy: �� virtlogd-admin.socket �� virtlogd.socket Docs: man:virtlogd(8) https://libvirt.org Main PID: 1968 (virtlogd) Tasks: 1 (limit: 19660) CPU: 16ms CGroup: /system.slice/virtlogd.service ��1968 /usr/sbin/virtlogd Jun 09 03:31:21 galadriel systemd[1]: Started Virtual machine log manager. Jun 09 03:31:21 galadriel virtlogd[1968]: libvirt version: 7.4.0 Jun 09 03:31:21 galadriel virtlogd[1968]: hostname: xxxxxxxx Jun 09 03:31:21 galadriel virtlogd[1968]: Unable to open system token /run/libvirt/common/system.token: Permission denied Disabling SElinux solves the error and virtlogd is started correctly. After which virsh is able to start VMs successfully. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1188075] motd displayed twice on screen
by bugzilla_noreply＠suse.com 07 Jul '21

07 Jul '21

https://bugzilla.suse.com/show_bug.cgi?id=1188075 https://bugzilla.suse.com/show_bug.cgi?id=1188075#c1 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Thorsten Kukuk <kukuk(a)suse.com> --- Already known and fixed, waiting somewhere in stagings. *** This bug has been marked as a duplicate of bug 1187536 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188075] New: motd displayed twice on screen
by bugzilla_noreply＠suse.com 07 Jul '21

07 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188075 Bug ID: 1188075 Summary: motd displayed twice on screen 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: felix.niederwanger(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 850815 --> http://bugzilla.opensuse.org/attachment.cgi?id=850815&action=edit Screenshot of the login screen, displaying the motd twice Hi, I've notices that on a fresh MicroOS installation, the motd is displayed twice. See the attached screenshot. # Reproducer 1. Edit /etc/motd (add anything) 2. Login via the normal login terminal After the password, the motd is displayed twice -- You are receiving this mail because: You are the assignee for the bug.

1 0

Your Bugzilla bug list needs attention.
by bugzilla_noreply＠suse.com 04 Jul '21

04 Jul '21

[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://bugzilla.suse.com/) that require attention. All of these bugs are in either the CONFIRMED, NEW, or REOPENED state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reset Assignee to default" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Ignore this email until you are actively working on this bug, when you should set the status to IN_PROGRESS. To get a list of all affected bugs, you can use this URL (bookmark it if you like!): http://bugzilla.suse.com/buglist.cgi?bug_status=CONFIRMED&bug_status=NEW&bu… Or, you can use the general query page, at http://bugzilla.suse.com/query.cgi Appended below are the individual URLs to get to all of your affected bugs that haven't been touched for 7 days or more. You will get this message once a week until you've dealt with these bugs! security enhancement: no setuid -> http://bugzilla.suse.com/show_bug.cgi?id=1171174 live-add-yast-repos: uses openSUSE-release -> http://bugzilla.suse.com/show_bug.cgi?id=1172100 transactional-update: warn about reboot etc. -> http://bugzilla.suse.com/show_bug.cgi?id=1173261 transactional-update: Notification on failing update -> http://bugzilla.suse.com/show_bug.cgi?id=1176882 [Build 20210128] openQA test fails in journal_check -> http://bugzilla.suse.com/show_bug.cgi?id=1181547 transactional server role has very inconsistent package selection (TW, SLE, Leap) -> http://bugzilla.suse.com/show_bug.cgi?id=1183582 Opening polari flatpak crashes packagekitd and makes gnome go back to login screen -> http://bugzilla.suse.com/show_bug.cgi?id=1184411 ignition doesn't reset firstboot -> http://bugzilla.suse.com/show_bug.cgi?id=1185461 kdump fails on microos -> http://bugzilla.suse.com/show_bug.cgi?id=1185463 Impossible to trigger PackageKit offline update on MicroOS -> http://bugzilla.suse.com/show_bug.cgi?id=1185647 Kubelet/CRI-O/CA-Advisor is not reporting memory -> http://bugzilla.suse.com/show_bug.cgi?id=1185801 selinux-ready error -> http://bugzilla.suse.com/show_bug.cgi?id=1186127 SElinux is blocking podman socket access to /var/run/podman/podman.sock -> http://bugzilla.suse.com/show_bug.cgi?id=1186158 snapper cleanup: Deleting snapshot failed. -> http://bugzilla.suse.com/show_bug.cgi?id=1186943 virtlogd cannot read token due to SElinux -> http://bugzilla.suse.com/show_bug.cgi?id=1187219 Snapshoot unusable (and "reverted") after updates, when SELinux enabled -> http://bugzilla.suse.com/show_bug.cgi?id=1187462

1 0

[Bug 1187897] New: Running kubelet1.21 on MicroOS Kubic crashes with Bus error
by bugzilla_noreply＠suse.com 01 Jul '21

01 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187897 Bug ID: 1187897 Summary: Running kubelet1.21 on MicroOS Kubic crashes with Bus error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: dom(a)capture.blue QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0 Build Identifier: When I try to run `kubelet --version` (or with any flags) I get: ``` Bus error (core dumped) ``` This is happening on a Raspberry Pi 4 using the aarch64 Kubic image. Strangely `kubelet1.20` works fine, but `kubelet1.21` crashes every time. I have SELinux installed, but I see the same behavior with it enabled/enforcing and when it's totally disabled. Reproducible: Always Steps to Reproduce: 1. Install Kubic 2. Run kubelet --version Actual Results: It crashes Expected Results: It shouldn't crash Here is the `strace` output from when the command crashes: ``` execve("/usr/bin/kubelet1.21", ["kubelet1.21", "--version"], 0xffffeed92038 /* 58 vars */) = 0 brk(NULL) = 0xaaaac2275000 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=14120, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 14120, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffffae88e000 close(3) = 0 openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\220l\0\0\0\0\0\0"..., 832) = 832 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=177672, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffae88c000 mmap(NULL, 213312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffffae822000 mprotect(0xffffae83d000, 81920, PROT_NONE) = 0 mmap(0xffffae851000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f000) = 0xffffae851000 mmap(0xffffae853000, 12608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffffae853000 close(3) = 0 openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\240\21\0\0\0\0\0\0"..., 832) = 832 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=72896, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 131168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffffae801000 mprotect(0xffffae804000, 114688, PROT_NONE) = 0 mmap(0xffffae820000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0xffffae820000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0@K\2\0\0\0\0\0"..., 832) = 832 pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\327\225\343\235t\\\213+\201\232\3:\220n\346\215"..., 68, 768) = 68 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1847400, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 1616440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffffae676000 mprotect(0xffffae7de000, 86016, PROT_NONE) = 0 mmap(0xffffae7f3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16d000) = 0xffffae7f3000 mmap(0xffffae7f9000, 31288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffffae7f9000 close(3) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffae88a000 mprotect(0xffffae7f3000, 12288, PROT_READ) = 0 mprotect(0xffffae820000, 4096, PROT_READ) = 0 mprotect(0xffffae851000, 4096, PROT_READ) = 0 --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0xaaaabdedf000} --- +++ killed by SIGBUS (core dumped) +++ ``` -- You are receiving this mail because: You are the assignee for the bug.

1 0