May 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

[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 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 1182544] New: transactional-update fails when self-updating from old snapshot
by bugzilla_noreply＠suse.com 28 Jun '21

28 Jun '21

https://bugzilla.suse.com/show_bug.cgi?id=1182544 Bug ID: 1182544 Summary: transactional-update fails when self-updating from old snapshot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1638401/modules/imag e_checks/steps/13 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: dimstar(a)opensuse.org, kubic-bugs(a)opensuse.org Found By: openQA Blocker: Yes This test boots into an old MicroOS image. It fails because combustion failed to run, which is caused by transactional-updates self update: Feb 21 05:49:26.233585 localhost combustion[542]: New version found - updating... Feb 21 05:49:26.374352 localhost combustion[703]: Loading repository data... Feb 21 05:49:26.584979 localhost combustion[703]: Reading installed packages... Feb 21 05:49:26.884304 localhost combustion[703]: Retrieving package transactional-update-3.1.4-1.1.x86_64 (1/1), 54.6 KiB ( 73.1 KiB unpacked) Feb 21 05:49:27.121761 localhost combustion[703]: .........done] Feb 21 05:49:27.306095 localhost combustion[742]: Loading repository data... Feb 21 05:49:27.517683 localhost combustion[742]: Reading installed packages... Feb 21 05:49:27.771859 localhost combustion[742]: Retrieving package libtukit0-3.1.4-1.1.x86_64 (1/2), 128.4 KiB (283.7 KiB unpacked) Feb 21 05:49:28.000220 localhost combustion[742]: ..........done] Feb 21 05:49:28.002964 localhost combustion[742]: Retrieving package tukit-3.1.4-1.1.x86_64 (2/2), 55.9 KiB ( 85.2 KiB unpacked) Feb 21 05:49:28.148466 localhost combustion[742]: ......done] Feb 21 05:49:28.209932 localhost combustion[741]: /tmp/transactional-update.a1AVPfXW9o/usr/sbin/tukit: /lib64/libselinux.so.1: no version information available (required by /tmp/transactional-update.a1AVPfXW9o/usr/lib64/libtukit.so.0) Feb 21 05:49:28.215355 localhost combustion[542]: transactional-update 3.1.4 started Feb 21 05:49:28.217252 localhost combustion[542]: Options: shell Feb 21 05:49:28.271971 localhost combustion[542]: Separate /var detected. Feb 21 05:49:28.320210 localhost combustion[741]: tukit: /lib64/libselinux.so.1: no version information available (required by /tmp/transactional-update.a1AVPfXW9o/usr/lib64/libtukit.so.0) Feb 21 05:49:28.328102 localhost combustion[741]: Failure (dbus fatal exception). ... Feb 21 05:49:29.012290 localhost combustion[741]: ERROR: filesystem error: cannot copy: File exists [/run/netconfig] [/.snapshots/2/snapshot/run/netconfig] Feb 21 05:49:29.013155 localhost combustion[542]: Opening chroot in snapshot , continue with 'exit' Feb 21 05:49:29.013981 localhost combustion[877]: tukit: /lib64/libselinux.so.1: no version information available (required by /tmp/transactional-update.a1AVPfXW9o/usr/lib64/libtukit.so.0) Feb 21 05:49:29.015824 localhost combustion[877]: 2021-02-21 05:49:29 tukit 3.1.4 started ... ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-x86_64-microos-old2microosnext@64bit fails in [image_checks](https://openqa.opensuse.org/tests/1638401/modules/image_check… ## Test suite description Boot from existing, static MicroOS image and transactional-update dup to snapshot under test ## Reproducible Fails since (at least) Build [20210219](https://openqa.opensuse.org/tests/1636750) ## Expected result Last good: [20210218](https://openqa.opensuse.org/tests/1635223) (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