September 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 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 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 1190532] New: kdump.service fails on transactional systems after /etc/hosts modifications
by bugzilla_noreply＠suse.com 15 Sep '21

15 Sep '21

https://bugzilla.suse.com/show_bug.cgi?id=1190532 Bug ID: 1190532 Summary: kdump.service fails on transactional systems after /etc/hosts modifications Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: ptesarik(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: db7532(a)qq.com, iforster(a)suse.com, kubic-bugs(a)opensuse.org Found By: --- Blocker: --- How to reproduce: 1. Boot into a transactional system with read-only / 2. Change /etc/hosts or just "touch" it 3. reboot On the next boot, kdump.service fails: Sep 15 03:18:23.894220 localhost load.sh[1139]: Regenerating kdump initrd ... Sep 15 03:18:23.894220 localhost load.sh[1139]: dracut: Executing: /usr/bin/dracut --force --hostonly --omit "plymouth resume usrmount" "--compress=xz -0 --check=crc32" --add kdump /usr/lib/modules/5.14.1-5-default/initrd-kdump 5.14.1-5-default Sep 15 03:18:23.894220 localhost load.sh[1139]: dracut: No permission to write to /usr/lib/modules/5.14.1-5-default. Sep 15 03:18:23.894900 localhost systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Sep 15 03:18:23.895117 localhost systemd[1]: kdump.service: Failed with result 'exit-code'. Sep 15 03:18:23.895457 localhost systemd[1]: Failed to start Load kdump kernel and initrd. Sep 15 03:18:23.895840 localhost systemd[1]: kdump.service: Consumed 1.607s CPU time. This is because the service tries to regenerate initrd-kdump if it is older than /etc/hosts. Initially found by openQA: https://openqa.opensuse.org/tests/1915952#step/trup_smoke/15 The problem was masked before the "trup_smoke" test was introduced, because a different test module called "transactional-update pkg in foo.rpm", which triggers "transactional-update kdump" as well. I don't think there's a single simple way to address this: 1. Leave it as an error and tell the user that "transactional-update kdump" needs to be run explicitly? 2. Don't attempt to rebuild the kdump initrd if / is read-only, thus effectively ignore /etc/hosts changes and rely on transactional-update calling mkdumprd regularly? 3. Move the kdump initrd into a location where it can be written even on read-only systems? 2 might be the best option. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190529] New: [Build 20210914] openQA test fails in podman_image
by bugzilla_noreply＠suse.com 15 Sep '21

15 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1190529 Bug ID: 1190529 Summary: [Build 20210914] openQA test fails in podman_image Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1917796/modules/podm an_image/steps/64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic 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 opensuse-Tumbleweed-NET-x86_64-containers_tw_image_on_ubuntu_host@64bit fails in [podman_image](https://openqa.opensuse.org/tests/1917796/modules/podman_imag… This failure happens when testing TW containers on Ubuntu, but as we don't even get to launching any container, the issue must be in the devel:kubic:libcontainers:stable project. Error reported: [33mWARN[0m[0000] Error validating CNI config file /etc/cni/net.d/87-podman.conflist: [failed to find plugin "bridge" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin] failed to find plugin "portmap" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin] failed to find plugin "firewall" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin] failed to find plugin "tuning" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin]] 942614226bb625543364b7283a89d746355cd5f8ea7fbed0e9a7f962ceea8c1c ## Test suite description Runs docker and podman container test on Ubuntu ## Reproducible Fails since (at least) Build [20210913](https://openqa.opensuse.org/tests/1915180) ## Expected result Last good: [20210912](https://openqa.opensuse.org/tests/1913682) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1190407] kubelet failed to create pod network sandbox: unable to set hairpin mode
by bugzilla_noreply＠suse.com 15 Sep '21

15 Sep '21

https://bugzilla.suse.com/show_bug.cgi?id=1190407 https://bugzilla.suse.com/show_bug.cgi?id=1190407#c2 --- Comment #2 from Stuart Bentley <s(a)stuartpb.com> --- Searching for "systemd-networkd weave", I came across this issue that may explain what's going wrong here: https://github.com/kontena/kontena/issues/1285#issuecomment-258905209 The network rule I set up to configure DHCP for my system had a match rule of `Type=ether`, which appears to match the veth interfaces created by Weave, causing systemd-networkd to try to manage them with DHCP. I'm amending the match rule to `Name=eth*`, and will see if that resolves the issue. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1190407] kubelet failed to create pod network sandbox: unable to set hairpin mode
by bugzilla_noreply＠suse.com 13 Sep '21

13 Sep '21

https://bugzilla.suse.com/show_bug.cgi?id=1190407 https://bugzilla.suse.com/show_bug.cgi?id=1190407#c1 --- Comment #1 from Thorsten Kukuk <kukuk(a)suse.com> --- We don't test with systemd-networkd, only wicked. Could be very well that some of the involved tools don't work together with systemd-networkd. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1190407] New: kubelet failed to create pod network sandbox: unable to set hairpin mode
by bugzilla_noreply＠suse.com 11 Sep '21

11 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1190407 Bug ID: 1190407 Summary: kubelet failed to create pod network sandbox: unable to set hairpin mode Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: s(a)stuartpb.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm trying to roll out a fresh Kubernetes cluster on nodes running Kubic (using systemd-networkd, if that could be related). Shortly after running `kubeadm init` and `KUBECONFIG=/etc/kubernetes/admin.conf kubectl apply -f /usr/share/k8s-yaml/weave/weave.yaml` to add the CNI, then pasting the join command into other nodes, I'm seeing pods fail to start with events like this (on a coredns pod): ``` Warning FailedCreatePodSandBox 5m49s kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-758b886957-ps5wc_kube-system_ddf332ce-dc22-4a03-8e4a-d5ee904936be_0(1a3938c9b41b9f0186a8e156b11b608bf606a7ed510df158921c09009063263e): error adding pod kube-system_coredns-758b886957-ps5wc to CNI network "weave": unable to allocate IP address: Post "http://127.0.0.1:6784/ip/1a3938c9b41b9f0186a8e156b11b608bf606a7ed510df15892…": dial tcp 127.0.0.1:6784: connect: connection refused Warning FailedCreatePodSandBox 5m35s kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-758b886957-ps5wc_kube-system_ddf332ce-dc22-4a03-8e4a-d5ee904936be_0(ee4eb51fb8e49730c1d40d28af0116e2b34f9ad7d38abc67bcd91d112a20d7f9): error adding pod kube-system_coredns-758b886957-ps5wc to CNI network "weave": unable to set hairpin mode to true for bridge side of veth vethweplee4eb51: operation not supported Warning FailedCreatePodSandBox 5m20s kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-758b886957-ps5wc_kube-system_ddf332ce-dc22-4a03-8e4a-d5ee904936be_0(6eea0c1bf1cb6cc9a6cd10901f34acbe2db16995105322dd03f35d2062e62c8f): error adding pod kube-system_coredns-758b886957-ps5wc to CNI network "weave": unable to set hairpin mode to true for bridge side of veth vethwepl6eea0c1: operation not supported Warning FailedCreatePodSandBox 5m7s kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_coredns-758b886957-ps5wc_kube-system_ddf332ce-dc22-4a03-8e4a-d5ee904936be_0(0a6110d500f0dffc97244f1836a2a99240e401c6fe8331d4df13ee43349fafb6): error adding pod kube-system_coredns-758b886957-ps5wc to CNI network "weave": unable to set hairpin mode to true for bridge side of veth vethwepl0a6110d: operation not supported ``` This happens for other pods I add to the cluster, too (for example, when installing Flux 2): they all get stuck with errors like this. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1190383] New: transactional-update fails when systemd-resolved is in use
by bugzilla_noreply＠suse.com 10 Sep '21

10 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1190383 Bug ID: 1190383 Summary: transactional-update fails when systemd-resolved is in use Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: s(a)stuartpb.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Also reported on GitHub: https://github.com/openSUSE/transactional-update/issues/70 On my MicroOS Kubic systems running systemd-resolved, any calls to transactional-update fail, as the `/run/systemd/resolve` directory can't be copied into the snapshot: ``` # transactional-update shell Checking for newer version. transactional-update 3.5.2 started Options: shell Separate /var detected. 2021-09-09 18:09:29 tukit 3.5.2 started 2021-09-09 18:09:29 Options: -c129 open 2021-09-09 18:09:30 Using snapshot 129 as base for new snapshot 130. 2021-09-09 18:09:30 Syncing /etc of previous snapshot 128 as base into new snapshot "/.snapshots/130/snapshot" 2021-09-09 18:09:31 Discarding snapshot 130. ERROR: filesystem error: cannot copy: Operation not supported [/run/systemd/resolve] [/.snapshots/130/snapshot/run/systemd/resolve] transactional-update finished ``` Steps to reproduce: In a fresh MicroOS instance, replace wicked with systemd-resolved using a series of commands like this: ``` transactional-update shell zypper install systemd-network systemctl disable wicked.service # disable DNSSEC globally sed -i '/^#\?DNSSEC=/{s/^#//;s/=.*$/=no/}' /etc/systemd/resolved.conf systemctl enable systemd-networkd.service systemd-resolved.service ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf echo '[Match] Type=ether [Network] DHCP=yes DNSOverTLS=opportunistic [DHCPv4] UseDomains=yes RouteMetric=10 [DHCPv6] RouteMetric=10 ' > /etc/systemd/network/80-dhcp.network ``` Reboot and attempt `transactional-update shell` again. The command fails. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1190365] root home directory appears to be mounting with wrong permissions
by bugzilla_noreply＠suse.com 10 Sep '21

10 Sep '21

https://bugzilla.suse.com/show_bug.cgi?id=1190365 https://bugzilla.suse.com/show_bug.cgi?id=1190365#c3 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt(a)suse.com, | |s(a)stuartpb.com Flags| |needinfo?(s(a)stuartpb.com) --- Comment #3 from Fabian Vogt <fvogt(a)suse.com> --- This can happen if the subvolumes are not mounted and the mountpoint directory itself is visible. What's the output of findmnt? Please attach the full journal of the first boot as well. I just checked https://download.opensuse.org/repositories/devel:/kubic:/images/openSUSE_Fa… and it looks ok. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1190365] New: root home directory appears to be mounting with wrong permissions
by bugzilla_noreply＠suse.com 10 Sep '21

10 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1190365 Bug ID: 1190365 Summary: root home directory appears to be mounting with wrong permissions Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: s(a)stuartpb.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- See this forum post: https://forums.opensuse.org/showthread.php/559581-Can-t-SSH-in-to-Kubic-aft… On a fresh installation of Kubic for Raspberry Pi from the images at https://download.opensuse.org/repositories/devel:/kubic:/images/openSUSE_Fa… (specifically https://download.opensuse.org/repositories/devel:/kubic:/images/openSUSE_Fa…) I can't SSH in as root, because the subvolume for the `/root` directory is not mounting with appropriate permissions, cf. these messages in the log: ``` Sep 09 17:24:07 localhost sshd[2360]: Authentication refused: bad ownership or modes for directory /root ``` I'm not sure what those bad modes are, but I know the directory comes up with write permissions for group and other when I mount it on another machine. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1183521] [Build 20210312] openQA test fails in transactional_update
by bugzilla_noreply＠suse.com 09 Sep '21

09 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183521 http://bugzilla.opensuse.org/show_bug.cgi?id=1183521#c5 --- Comment #5 from Ignaz Forster <iforster(a)suse.com> --- This bug had been fixed (a long time ago) in transactional-update 3.3.0: The link to the RPM database is created as a relative link now. The workdir issue is a bit more tricky, as we can't fix the old transactional-update version. The bug was triggered when using an old transactional-update version < 3.0, explicitly stating --no-selfupdate, on a snapshot created with a transactional-update version >= 3.0; the *old* transactional-update would fail to recognize the /etc overlay due to a changed path of the workdir and not create a new overlay for this snapshot. The *new* transactional-update will then fail to use that snapshot due to the missing overlay for the snapshot. Support for snapshots without corresponding overlay has been added meanwhile, so the problem should at least fix itself. -- You are receiving this mail because: You are on the CC list for the bug.

1 0