July 2021 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[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