September 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1202851] New: Shutdown or reboot of VirtualBox guest with usb device attached causes guest to abort
by bugzilla_noreply＠suse.com 22 Nov '22

22 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202851 Bug ID: 1202851 Summary: Shutdown or reboot of VirtualBox guest with usb device attached causes guest to abort Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: David.Boyd49(a)twc.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Tumbleweed server with VirtualBox 6.1.36 installed. Testing with many guests: Arch Linux, debian, fedora (stable and rawhide), FreeBSD, Linux Mint, openSUSE LEAP 15.4, openSUSE Tumbleweed. If a USB device (usually a flash drive) is attached when the guest is shutdown or rebooted, the guest ends with an "Aborted" status. This is new with 6.1.36 of VirtualBox from the opensuse Tumbleweed repository. This problem is a nuisance with shutdown but precludes a successful reboot requiring user attention. This issue is not observed when openSUSE LEAP 15.4 is the host. There are no useful messages in the log(s). If the user remembers to detach the USB device before rebooting, the problem can be avoided. Yeah, like that's going to happen. -- You are receiving this mail because: You are on the CC list for the bug.

1 19

[Bug 1203749] New: dracut: kernel configfs fails to mount in the initrd
by bugzilla_noreply＠suse.com 22 Nov '22

22 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1203749 Bug ID: 1203749 Summary: dracut: kernel configfs fails to mount in the initrd Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: dracut-maintainers(a)suse.de Reporter: antonio.feijoo(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- sys-kernel-config.mount needs modprobe(a)configfs.service since systemd v246.7 (https://github.com/systemd/systemd/commit/42cc2855) so the kernel configfs fails to mount in the initrd. Fixed upstream (https://github.com/dracutdevs/dracut/commit/928252a1) this patch needs to be backported to TW and from SLE15-SP3 (Leap 15.3) onwards. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1202503] New: The power management applet is missing
by bugzilla_noreply＠suse.com 22 Nov '22

22 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202503 Bug ID: 1202503 Summary: The power management applet is missing Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: sokolovskymaximorg(a)duck.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello. While working, I noticed that there is no power management of my laptop on my distribution kit in gnome. There is neither an applet in the dock, nor a similar function in the gnome parameters. After looking through the forums, I realized that gnome-power-manager is responsible for this. What is strange is that this package was not installed in the system. But even after installing the power management function did not appear. Also, the problem was encountered by a person from an opensuse chat with kde as a working environment. Therefore, I cannot understand this is a tumbleweed problem or a graphical environment. Thank you in advance for your help -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1178338] New: [installation] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support)
by bugzilla_noreply＠suse.com 22 Nov '22

22 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1178338 Bug ID: 1178338 Summary: [installation] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: jslaby(a)suse.com QA Contact: jsrain(a)suse.com CC: glin(a)suse.com, jens(a)krieger-juhnke.de, jlee(a)suse.com, jslaby(a)suse.com, mbenes(a)suse.com, mchang(a)suse.com, tiwai(a)suse.com Blocks: 1172292 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1172292 +++ On some devices (In my case a Lenovo Ideapad 100s-11iby) have 64 bit processors, but a 32-bit UEFI, so the 64-bit installation mediums are not recognized by it. Steps to Reproduce: 1. Grab a device with a 64-bit processor and a 32-bit UEFI 2. Try to boot from a 64-bit installation medium Actual Results: The installation medium is not listed in the boot menu. Expected Results: The installation medium is listed correctly, just like on a machine with a 64-bit UEFI. I did a bit of research, and found out the following: Fedora has natively supported 32-bit UEFI for 64 bit installs since Fedora 27. There seems to be a a workaround, but this is not very practical for new users, which adds a file from Github (https://github.com/hirotakaster/baytail-bootia32.efi) to the installation medium. ===================== Could x86_64 installation media contain this file on the installation media in the EFI partition: EFI/boot/bootia32.efi ? It should be copied from /usr/share/efi/i586/grub.efi from grub2-i386-efi package, the same as is EFI/boot/bootx64.efi from grub2-x86_64-efi. This will add support for 32bit FW with 64-bit CPUs. It used to work fine when I tried last time on such a machine. I had EFI/boot/bootia32.efi on an USB stick and loaded config from a DVD. Then continued the installation the usual way. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1202138] New: PowerPC machine crashes frequently after upgrading to Leap 15.4
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 Bug ID: 1202138 Summary: PowerPC machine crashes frequently after upgrading to Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: PowerPC-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: marius.kittler(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After upgrading a PowerPC machine (the openQA worker qa-power8-4-kvm.qa.suse.de) from Leap 15.3 to Leap 15.4 that machine crashes frequently. It usually does not stay on for more than a few hours. Downgrading the machine (by rolling back to the last BTRFS snapshot with Leap 15.3) allows the machine to run stable again. Note that there's actually a second machine (the openQA worker qa-power8-5-kvm.qa.suse.de) that we managed to operate without crashes on Leap 15.4. Both machines seems very similar to me so I'm not sure whether one is crashing and the other one not. Note that in the first place both machines did not boot on Leap 15.4. It seemed to be stuck at some point and the kernel logged messages like ``` [ 197.877239][ C62] watchdog: BUG: soft lockup - CPU#62 stuck for 25s! [swapper/62:0]` quite frequently ``` quite frequently. So I added the kernel parameter `nmi_watchdog=0`. With this parameter both machines could boot on Leap 15.4 (but as mentioned only qa-power8-5 runs stable without crashing). So the kernel command line used is: ``` root=UUID=89ca2dff-86af-478b-8d4c-2a45ca689fd5 nospec kvm.nested=1 kvm_intel.nested=1 kvm_amd.nested=1 kvm-arm.nested=1 crashkernel=210M nmi_watchdog=0 ``` Not sure what other details could be relevant. Unfortunately the journal does not have any interesting message right before the crash. Via SOL I could once see a kernel panic being logged: ``` QA-Power8-4-kvm login: [ 365.807470][ T3923] EXT4-fs error (device sdb1) in ext4_free_inode:362: Corrupt filesystem [ 438.050890][ T94] Kernel panic - not syncing: corrupted stack end detected inside scheduler [ 438.051046][ T94] CPU: 16 PID: 94 Comm: ksof ``` (The filesystem error is likely just a symptom of the crashes.) Any advice what I could try? Maybe another kernel parameter? Maybe booting Leap 15.4 but with the kernel version from 15.3 (not sure how I'd do that, though - so any advice would be welcome if that idea sounds helpful)? By the way, that's `/proc/cpuinfo` on the problematic machine: ``` root=UUID=eebe647f-e867-416e-a0fa-7a6732bfcf9d nospec kvm.nested=1 kvm_intel.nested=1 kvm_amd.nested=1 kvm-arm.nested=1 crashkernel=210M martchus@QA-Power8-4-kvm:~> cat /proc/cpuinfo processor : 0 cpu : POWER8, altivec supported clock : 3857.000000MHz revision : 2.0 (pvr 004d 0200) [�� repeated 7 more times with processor 8, 16, 24, 32, 40, 48 and 56] timebase : 512000000 platform : PowerNV model : 8348-21C machine : PowerNV 8348-21C firmware : OPAL MMU : Hash ``` On the stable machine it looks very similar but it is actually a model with more processors: ``` processor : 0 cpu : POWER8 (raw), altivec supported clock : 3857.000000MHz revision : 2.0 (pvr 004d 0200) [�� repeated 13 more times with processor 8, 16, 24, ��] timebase : 512000000 platform : PowerNV model : 8335-GCA machine : PowerNV 8335-GCA firmware : OPAL MMU : Hash ``` That's the relevant ticket on the openQA infrastructure tracker (for additional context): https://progress.opensuse.org/issues/114565 -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 1196085] New: Calling external programs from YaST fragile with full paths
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1196085 Bug ID: 1196085 Summary: Calling external programs from YaST fragile with full paths Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: shundhammer(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- After a security audit some years ago we changed all calls to external programs in YaST to use the full path, i.e. from "foobar" to "/sbin/foobar". The rationale was that this would prevent a potential attacker from manipulating the $PATH to include some directory containing a malicious version of the program, i.e. a "/my/hacked/foobar" with $PATH also containing "/my/hacked". With the transition from /bin to /usr/bin and /sbin to /usr/sbin that turned out to be a bad idea since now we need to update those full paths in the YaST code whenever any of those binaries makes that transition, i.e. it's moved from /sbin to /usr/sbin. Worse, if the transition is done in one supported product like Tumbleweed or Leap, yet another one like SLES still uses the old path, we would have to maintain different paths (and not forget to adapt them when that other product makes that transition as well); or we would need to create our own fallback logic to search all the possible paths which one to invoke. But that fallback logic exists, and if handled correctly, it's just as secure as using a full path; but more flexible and not fragile against tools being moved from one system location to another: It's $PATH. We need to make sure that $PATH only contains directories that are not writeable by non-privileged users, and of course not "." (the current directory) or any path that starts with "."; e.g. export PATH="/usr/sbin:/usr/bin:/sbin:/bin" And we already do that in YaST code. So we should migrate calls to external programs back to calling them without the full path and use our secure $PATH instead. For a more in-depth discussion, see also https://github.com/yast/yast-iscsi-client/issues/111 -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 1190524] New: baloo keeps my laptop hot
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190524 Bug ID: 1190524 Summary: baloo keeps my laptop hot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: saba(a)sabanet.at 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: Baloo file indexer is running since days at 100% CPU and I'm not sure if it will ever finish. Reproducible: Always Steps to Reproduce: 1. Installed Tumbleweed from scratch on a brand new notebook (LG gram 2021 i7-1165G7) 2. Copied my home directory from my old laptop (approx. 700GB of data) 3. Watch baloo running at 100% CPU for days/weeks Actual Results: Baloo seems to get slower and slower: gram:~> balooctl status ; sleep 3600 ; balooctl status Baloo File Indexer is running Indexer state: Indexing file content Total files indexed: 3,683,585 Files waiting for content indexing: 160,364 Files failed to index: 0 Current size of index is 71.48 GiB Baloo File Indexer is running Indexer state: Indexing file content Total files indexed: 3,683,065 Files waiting for content indexing: 159,844 Files failed to index: 0 Current size of index is 71.48 GiB This means in one hour the number of files waiting to be indexed decreased only by 520 (which would mean 7 seconds to add a single file to the index). At this speed, I'd need to wait another 300 hours before the indexer completed its job. Expected Results: Indexing should complete *much* faster. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1193838] New: LXC /etc/systemd/system.conf is marked executable??
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193838 Bug ID: 1193838 Summary: LXC /etc/systemd/system.conf is marked executable?? Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dev.dorrejo(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, i am practicing LXC, and have the next issue: zypper in --no-recommends lxc Configuration file /etc/systemd/system.conf is marked executable. Please remove executable permission bits. Proceeding anyway. ll /etc/systemd/system.conf -rw-r--r-- 1 root root 1993 Nov 24 19:14 /etc/systemd/system.conf getfacl /etc/systemd/system.conf # file: etc/systemd/system.conf # owner: root # group: root user::rw- group::r-- other::r-- Environment: - VMs using tumbleweed up-to-date - Disabled AppArmor - cgroup systemd.unified_cgroup_hierarchy=0 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1196335] New: [Build C.520.1] kdump failed to start: device or resource busy
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196335 Bug ID: 1196335 Summary: [Build C.520.1] kdump failed to start: device or resource busy Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://openqa.opensuse.org/tests/2204439/modules/jour nal_check/steps/22 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-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 microos-Staging:C-Staging-DVD-x86_64-container-host-microos@64bit-2G-HD40G fails in [journal_check](https://openqa.opensuse.org/tests/2204439/modules/journal_ch… This error appears sporadic, rerunning the test might or might not show the same error: Feb 23 09:28:47.073824 localhost.localdomain systemd[1]: Failed to start Load kdump kernel and initrd. Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: kexec_load failed: Device or resource busy Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: entry = 0x7f554760 flags = 0x3e0001 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: nr_segments = 6 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].buf = 0x7f8e0c0ae010 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].bufsz = 0x13fbbb4 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].mem = 0x7a804000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].memsz = 0x13fc000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].buf = 0x7f8e0d4ade10 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].bufsz = 0xb0bdb0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].mem = 0x7bc00000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].memsz = 0x37b4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].buf = 0x5649202ba900 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].bufsz = 0x3fc7 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].mem = 0x7f550000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].memsz = 0x4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].buf = 0x5649202b36c0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].bufsz = 0x70e0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].mem = 0x7f554000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].memsz = 0x9000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].buf = 0x5649202b1860 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].bufsz = 0x400 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].mem = 0x7f55d000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].memsz = 0x4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].buf = 0x7f8e0c00f010 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].bufsz = 0x9ec00 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].mem = 0x7f561000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].memsz = 0x9f000 Feb 23 09:28:47.071528 localhost.localdomain kdump[991]: FAILED to load kdump kernel: /sbin/kexec -p /boot/vmlinuz-5.16.10-5-default --append=" rd.timeout=60 rd.retry=45 console=ttyS0 console=tty kernel.softlockup_panic=1 swapaccount=1 quiet security=selinux selinux=1 enforcing=1 mitigations=auto elevator=deadline sysrq=yes reset_devices acpi_no_memhotplug cgroup_disable=memory nokaslr numa=off irqpoll nr_cpus=1 root=kdump rootflags=bind rd.udev.children-max=8 disable_cpu_apicid=0 panic=1" --initrd=/boot/initrd-kdump , Result: kexec_load failed: Device or resource busy entry = 0x7f554760 flags = 0x3e0001 nr_segments = 6 segment[0].buf = 0x7f8e0c0ae010 segment[0].bufsz = 0x13fbbb4 segment[0].mem = 0x7a804000 segment[0].memsz = 0x13fc000 segment[1].buf = 0x7f8e0d4ade10 segment[1].bufsz = 0xb0bdb0 segment[1].mem = 0x7bc00000 segment[1].memsz = 0x37b4000 segment[2].buf = 0x5649202ba900 segment[2].bufsz = 0x3fc7 segment[2].mem = 0x7f550000 segment[2].memsz = 0x4000 segment[3].buf = 0x5649202b36c0 segment[3].bufsz = 0x70e0 segment[3].mem = 0x7f554 Feb 23 09:28:47.073246 localhost.localdomain systemd[1]: kdump.service: Main process exited, code=exited, status=255/EXCEPTION Feb 23 09:28:47.073509 localhost.localdomain systemd[1]: kdump.service: Failed with result 'exit-code'. ## Test suite description ## Reproducible Fails since (at least) Build [C.520.1](https://openqa.opensuse.org/tests/2204217) ## Expected result Last good: [C.519.7](https://openqa.opensuse.org/tests/2203451) (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 7

[Bug 1082318] New: Packages must not mark license files as %doc
by bugzilla_noreply＠novell.com 21 Nov '22

21 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1082318 Bug ID: 1082318 Summary: Packages must not mark license files as %doc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Certain licenses require that license files must be shipped together with the binaries in all cases. By using the %doc marker, this is no longer guaranteed (e.g. by enabling excludedocs). Thus it is important that for such cases, %license is used instead of %doc. The effect is that the file is always installed, stored in a different directory (/usr/share/licenses/<pkg>/) and can be queried using rpm (e.g. "rpm -qL kernel-firmware"). -- You are receiving this mail because: You are on the CC list for the bug.

2 249