July 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1189283] New: kernel-obs-build needs af_alg
by bugzilla_noreply＠suse.com 28 Feb '23

28 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1189283 Bug ID: 1189283 Summary: kernel-obs-build needs af_alg Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- libkcapi got updated to 1.3.1 (https://build.opensuse.org/request/show/910806) and apparently gnutls picks that up now and enables support for it. It seems like that depends on AF_ALG sockets though, which are currently not enabled in kernel-obs-build (missing af_alg module), so various builds (libzip, libvirt) fail with libkcapi - Error: AF_ALG: socket syscall failed (errno: -97) I'm not sure whether just af_alg is enough, it might need some other modules as well. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1201784] New: switch_to_fb linuxrc option duplicates kernel functionality
by bugzilla_noreply＠suse.com 28 Feb '23

28 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1201784 Bug ID: 1201784 Summary: switch_to_fb linuxrc option duplicates kernel functionality Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- To me it looks like switch_to_fb= duplicates functionality from console= If it is not specified, "the OS" should just use what the kernel thinks the console is. In practice this is either the monitor. Or it can be a serial device, like on non-x86 the kernel will reuse the firmware output device. In case the admin wants to have a specific console, and the default does not fit, the will documented console=tty1|ttyS0|ttyAMA0 option will deal with it. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1173619] New: VUL-0: unbound: LPE from unbound to root
by bugzilla_noreply＠suse.com 27 Feb '23

27 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1173619 Bug ID: 1173619 Summary: VUL-0: unbound: LPE from unbound to root Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: darin(a)darins.net Reporter: wolfgang.frisch(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- via security(a)suse.de: I believe to have found a configuration issue in the Unbound package. Or, depending on how you look at it, in the Unbound server itself. 1. Before starting the Unbound server, systemd routinely runs unbound-anchor. From 'systemctl cat unbound': ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem As you can see this process is run as user unbound. 2. The Unbound server writes a pid file before dropping privileges, i.e. as root. It then chown's the file in a second step. 'grep username /etc/unbound/unbound.conf': username: "unbound" And from the Unbound source: https://github.com/NLnetLabs/unbound/blob/2a90e8fa1e22aa75d1cf67a1f71ebbf3f… As you can see in the source, Unbound doesn't check if there is already a symbolic link in place of the pid file. 3. openSUSE configures Unbound to create the pid file in a directory owned by the unbound user. 'grep pidfile /etc/unbound/unbound.conf': pidfile: "/var/run/unbound/unbound.pid" 'cat /usr/lib/tmpfiles.d/unbound.conf': D /run/unbound 0755 unbound unbound - 4. unbound-anchor is a nice little "do-one-thing-and-do-it-right" tool. But if it is compromised, and as it has write permission in the pid file directory and reliably runs before the server, an attacker could easily gain full root privileges by just creating a symbolic link /run/unbound/unbound.pid. 5. IMHO this would be best fixed in openSUSE by creating a root owned /run/unbound directory, or changing the pid file path to /run/unbound.pid or something like that. I think this would have the added advantage that openSUSE could ship and maybe enforce the Unbound AppArmor profile used in Debian and Ubuntu: https://gitlab.com/apparmor/apparmor-profiles/-/blob/master/ubuntu/20.04/us… With the current openSUSE setup there is the problem that if AppArmor filters CAP_DAC_OVERRIDE, Unbound has no permission to create a pid file in /run/unbound anymore. If you have questions please don't hesitate to contact me. Thanks for taking a look. Kind regards, Detlef -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1181471] New: libcurl hangs in a __poll below curl_easy_cleanup
by bugzilla_noreply＠suse.com 27 Feb '23

27 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1181471 Bug ID: 1181471 Summary: libcurl hangs in a __poll below curl_easy_cleanup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: ma(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi Predro, a puzzle for the curl maintainers. I'm lost how to further investigate it. Maybe you've got an idea: [https://github.com/openSUSE/zypper/issues/364] - 'Proot' is used to chroot into an openSUSE TW system. This might be the reason, at least ZYPP never received a similar issue report, neither on aarch64 nor on any other architecture. From within the system, libzypp (via libcurl) is able to connect to e.g. download. opensuse.org (the log shows a successful head request). But when closing the connection libcurl reproducible hangs below a call to curl_easy_cleanup (for 20+ minutes before killing zypper). A stacktrace created by libzypp shows curl_easy_cleanup staying in a call to poll: > [bt]: (0) /lib64/libc.so.6 : __poll+0xec [0x7f8a71618c] > [bt]: (1) /usr/lib64/libcurl.so.4 : +0x5e088 [0x7f8a54f088] > [bt]: (2) /usr/lib64/libcurl.so.4 : +0x6024c [0x7f8a55124c] > [bt]: (3) /usr/lib64/libcurl.so.4 : +0x47240 [0x7f8a538240] > [bt]: (4) /usr/lib64/libcurl.so.4 : +0x4740c [0x7f8a53840c] > [bt]: (5) /usr/lib64/libcurl.so.4 : +0x1a3c4 [0x7f8a50b3c4] > [bt]: (6) /usr/lib64/libcurl.so.4 : +0x6e7d0 [0x7f8a55f7d0] > [bt]: (7) /usr/lib64/libcurl.so.4 : curl_easy_cleanup+0x40 [0x7f8a506db0] > [bt]: (8) /usr/lib64/libzypp.so.1722 : zypp::media::MediaCurl::disconnectFrom()+0x2c [0x7f8ada0bdc] > [bt]: (9) /usr/lib64/libzypp.so.1722 : zypp::media::MediaHandler::disconnect()+0x34 [0x7f8ad8bab4] The same is seen in the strace log: > https://github.com/openSUSE/zypper/files/5856500/zypper.strace.log.zip > (search for 'Releasing media http<http://download.opensuse.org' After writing the log line libzypp calls curl_easy_cleanup. Then you see just an endless loop of ppoll calls. Any idea/hint how to circumvent this is welcome. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1194660] New: Installation does not find repositories
by bugzilla_noreply＠suse.com 27 Feb '23

27 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1194660 Bug ID: 1194660 Summary: Installation does not find repositories Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: axel.braun(a)gmx.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- In current Leap 15.3 build for aarch64 - when booting from NET-ISO, system hangs at Adding Repositories -> Download documentation - when booting from DVD, when reading list of online repositories (Unable to download list of repositories or no repositories defined) (Yes, there is an online connection ;-) -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1186332] New: Thinkpad X270: BUG: workqueue lockup - pool cpus=0-3 flags=0x5 nice=0 stuck for 35s!
by bugzilla_noreply＠suse.com 27 Feb '23

27 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1186332 Bug ID: 1186332 Summary: Thinkpad X270: BUG: workqueue lockup - pool cpus=0-3 flags=0x5 nice=0 stuck for 35s! Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: ptesarik(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 849559 --> https://bugzilla.suse.com/attachment.cgi?id=849559&action=edit dmesg after lockup I've just experienced a kernel stall on my Lenovo Thinkpad X270, attached. At this point I have no idea how to proceed, and no, I cannot reproduce the hang at will. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1199685] New: [doc] 3 Änderungen beim Paketieren
by bugzilla_noreply＠suse.com 27 Feb '23

27 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1199685 Bug ID: 1199685 Summary: [doc] 3 �nderungen beim Paketieren Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Release Notes Assignee: lukas.kucharczyk(a)suse.com Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: lubos.kocman(a)suse.com Found By: --- Blocker: --- 3 �nderungen beim Paketieren: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.4/#sec.packa… Broken Link: https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.star… -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1194322] New: eth0 report update as boot completes causes screen to clear, in spite of --noclean agetty option
by bugzilla_noreply＠suse.com 26 Feb '23

26 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1194322 Bug ID: 1194322 Summary: eth0 report update as boot completes causes screen to clear, in spite of --noclean agetty option Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de CC: sbrabec(a)suse.com Blocks: 1168405 Found By: --- Blocker: --- Created attachment 854979 --> http://bugzilla.opensuse.org/attachment.cgi?id=854979&action=edit /etc/systemd/system/getty.target.wants/getty(a)tty1.service Original Summary: eth0 report update as boot completes causes screen to clear, in spite of --noclean agetty option This began with TW very long ago and applies to 15.4 and 15.3 as well. 15.2 was OK. To reproduce: 1-uninstall or disable Plymouth 2-Include ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear %I $TERM in /etc/systemd/system/getty.target.wants/getty(a)tty1.service 3-boot without quiet or splash=silent, and with noresume added to, linu line in grub.cfg Actual behavior: 1-post KMS-engagement text messages appear onscreen ending with: a: Welcome to openSUSE...(tty1). b: eth0: c: <hostname> login: 2-screen clears to only: a: Welcome to openSUSE...(tty1). b: eth0: xxx.xxx.xxx.xxx c: <hostname> login: 3-EOF Expected behavior: 1-post KMS-engagement text messages appear onscreen ending with: a: Welcome to openSUSE...(tty1). b: eth0: c: <hostname> login: 2-EOF Other data: # systemd-analyze critical-chain ... ��multi-user.target @2.465s ��kbdsettings.service @400ms +2.064s ��basic.target @396ms ��sockets.target @396ms ��telnet.socket @396ms ��sysinit.target @394ms ��systemd-timesyncd.service @366ms +27ms ��systemd-tmpfiles-setup.service @356ms +8ms ��local-fs.target @355ms ��usr-local.mount @351ms +3ms ��systemd-fsck(a)dev-disk-by\x2dlabel-tm8p04usrlcl.service @330ms +19ms ��local-fs-pre.target @327ms ��lvm2-monitor.service @246ms +80ms ��dm-event.socket @239ms ��system.slice ��-.slice # systemctl status systemd-networkd �� systemd-networkd.service - Network Configuration Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2022-01-04 20:35:46 EST; 9min ago TriggeredBy: �� systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 572 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) CPU: 47ms CGroup: /system.slice/systemd-networkd.service ��572 /usr/lib/systemd/systemd-networkd Jan 04 20:35:46 ab560 systemd[1]: Starting Network Configuration... Jan 04 20:35:46 ab560 systemd-networkd[572]: lo: Link UP Jan 04 20:35:46 ab560 systemd-networkd[572]: lo: Gained carrier Jan 04 20:35:46 ab560 systemd-networkd[572]: Enumeration completed Jan 04 20:35:46 ab560 systemd[1]: Started Network Configuration. Jan 04 20:35:48 ab560 systemd-networkd[572]: eth0: Link UP Jan 04 20:35:51 ab560 systemd-networkd[572]: eth0: Gained carrier # rpm -qa | egrep -i 'NetworkManager|Wicked' # -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1191806] New: Argon 15.3 kde user feedback disappeared
by bugzilla_noreply＠suse.com 25 Feb '23

25 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1191806 Bug ID: 1191806 Summary: Argon 15.3 kde user feedback disappeared Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: epistemepromeneur(a)free.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- kde user feedback disappeared in kde settings Argon 15.3 plasma : 5.23.0 kde frameworks : 5.87.0 Qt : 5.15.2 kde gear 21.08.2 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1200290] New: kerberized nfs mounts on a client-only config due not work due to rpc.gssd not being started
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1200290 Bug ID: 1200290 Summary: kerberized nfs mounts on a client-only config due not work due to rpc.gssd not being started Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: mephisto(a)gmx.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Build Identifier: I installed a fresh version of OpenSUSE Leap 15.4 RC, and tried to mount kerberized nfs mounts. After configuring the mount in the yast2 nfs-client module, it fails to mount. The documentation gives the hint to execute systemctl start rpc-gssd.service after which the mount succeeds. However, this does not survive a reboot, rpc.gssd does not get startet. systemctl enable rpc-gssd.service fails. The only workaround I found was to install the nfs-server component as well, and to start the nfs kernel server with no exports. This actually brings up rpc.gssd, and mounts succeed. Please fix. Reproducible: Always Steps to Reproduce: 1. Setup kerberized NFS server 2. install fresh version of OpenSUSE Leap 15.4 3. install yast2-nfs-client + dependencies, but not nfs-kernel-server 4. configure the GSS-secured mount in yast2 nfs-client module Actual Results: mount fails with error message mount.nfs: an incorrect mount option was specified Expected Results: mount succeeds When manually starting rpc.gssd by systemctl start rpc-gssd.service, and mounting afterwards, the mount succeeds. After a reboot, rpc-gssd.service is again not running, and mount fails. -- You are receiving this mail because: You are on the CC list for the bug.

1 4