October 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1191727] New: Broadcom wi-fi card did not work after installing fresh tumbleweed
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1191727 Bug ID: 1191727 Summary: Broadcom wi-fi card did not work after installing fresh tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: virex(a)mail.ru QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- My Broadcom wi-fi-card on laptop did not work after installing fresh tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1179894] New: warnings in OBS builds from kernel+initrd about "Warning: running kernel does not support fscaps"
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1179894 Bug ID: 1179894 Summary: warnings in OBS builds from kernel+initrd about "Warning: running kernel does not support fscaps" 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: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de CC: fvogt(a)suse.com, jslaby(a)suse.com, msuchanek(a)suse.com, okurz(a)suse.com, thomas.blume(a)suse.com, tiwai(a)suse.com Depends on: 1178401 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1178401 +++ ## Observation https://build.opensuse.org/build/openSUSE:Factory/images/local/000product:o… shows repeated warnings about: ``` [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps [ 14s] Warning: running kernel does not support fscaps ``` ## Steps to reproduce Seemingly reproducible in any build of packages, e.g. https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/00… shows the same ## Expected result Only errors and warnings in the log that I as package/project maintainer can fix -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1178463] New: Flood of "usb usb{2,6}-port1: Cannot enable." messages
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1178463 Bug ID: 1178463 Summary: Flood of "usb usb{2,6}-port1: Cannot enable." messages 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: lmb(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 843325 --> https://bugzilla.suse.com/attachment.cgi?id=843325&action=edit lsusb -vv With the 5.10.0rc2 kernel from Kernel:HEAD, I'm experiencing a flood of: ... [ 372.567942] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 374.686509] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 377.026495] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 378.986503] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 381.446415] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 383.290504] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 385.918496] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 387.586478] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 390.386475] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 391.894454] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? ... The XPS 13 is connected to a Belkin Thunberbird dock. As far as I can tell, except for these messages, all USB connected peripherals (keyboard, mouse, webcam) are working. Attaching lsusb -vv and dmesg output. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1188487] New: BUG: workqueue lockup
by bugzilla_noreply＠suse.com 26 Jan '23

26 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1188487 Bug ID: 1188487 Summary: BUG: workqueue lockup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: tdevries(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I started seeing this bug on my tumbleweed system: ... 2021-07-07T16:24:41.803560+02:00 lena kernel: [1053710.804959] CPU: 3 PID: 31988 Comm: gdb Tainted: G D 5.12.10-1-default #1 openSUSE Tumbleweed Message from syslogd@lena at Jul 19 16:18:29 ... kernel:[722585.589404] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for inted: G D 5.12.10-1-default #1 openSUSE Tumbleweed 2021-07-07T16:24:41.803561+02:00 lena kernel: [1053710.804964] Hardware name: LENOVO 20F5S0KF00/20F5S0KF00, BIOS R02ET73W (1.46 ) 01/08/2020 2021-07-07T16:24:41.803563+02:00 lena kernel: [1053710.804966] Call Trace: 2021-07-07T16:24:41.803564+02:00 lena kernel: [1053710.804971] dump_stack+0x76/0x94 2021-07-07T16:24:41.803566+02:00 lena kernel: [1053710.804978] bad_page.cold+0x9b/0xa0 2021-07-07T16:24:41.803567+02:00 lena kernel: [1053710.804983] get_page_from_freelist+0x739/0x13a0 2021-07-07T16:24:41.803568+02:00 lena kernel: [1053710.804990] __alloc_pages_nodemask+0x161/0x310 2021-07-07T16:24:41.803569+02:00 lena kernel: [1053710.804993] pagecache_get_page+0x14c/0x4f0 2021-07-07T16:24:41.803570+02:00 lena kernel: [1053710.805000] grab_cache_page_write_begin+0 7-07T16:24:41.803572+02:00 lena kernel: [1053710.805009] iomap_write_actor+0x9f/0x1a0 2021-07-07T16:24:41.803573+02:00 lena kernel: [1053710.805013] iomap_apply+0x111/0x2e0 2021-07-07T16:24:41.803575+02:00 lena kernel: [1053710.805015] ? iomap_write_end+0x260/0x260 2021-07-07T16:24:41.803576+02:00 lena kernel: [1053710.805020] iomap_file_buffered_write+0x5c/0x80 2021-07-07T16:24:41.803577+02:00 lena kernel: [1053710.805023] ? iomap_write_end+0x260/0x260 2021-07-07T16:24:41.803578+02:00 lena kernel: [1053710.805026] xfs_file_buffered_write+0xbd/0x2b0 [xfs] 2021-07-07T16:24:41.803579+02:00 lena kernel: [1053710.805122] ? _flat_send_IPI_mask+0x21/0x40 2021-07-07T16:24:41.803580+02:00 lena kernel: [1053710.805128] ? generic_exec_single+0x50/0xc0 2021-07-07T16:24:41.803582+02:00 lena kernel: [1053710.805133] ? smp_call_function_single_async+0x17/0x20 2021-07-07T16:24:41.803583+02:00 lena kernel: [1053710.805138] new_sync_write+0x11c/0x1b0 2021-07-07T16:24:41.803583+02:00 lena kernel: [1053710.805143] vfs_write+0x1b8/0x270 2021-07-07T16:24:41.803585+02:00 lena kernel: [1053710.805146] ksys_write+0x5f/0xe0 2021-07-07T16:24:41.803586+02:00 lena kernel: [1053710.805150] do_syscall_64+0x33/0x80 2021-07-07T16:24:41.803587+02:00 lena kernel: [1053710.805155] entry_SYSCALL_64_after_hwframe+0x44/0xae 2021-07-07T16:24:41.803588+02:00 lena kernel: [1053710.805159] RIP: 0033:0x7fc4b3b4539f 2021-07-07T16:24:41.803589+02:00 lena kernel: [1053710.805162] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 b9 49 f9 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 0c 4a f9 ff 48 2021-07-07T16:24:41.803590+02:00 lena kernel: [1053710.805167] RSP: 002b:00007fff61dfb5f0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 2021-07-07T16:24:41.803592+02:00 lena kernel: [1053710.805171] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007fc4b3b4539f 2021-07-07T16:24:41.803592+02:00 lena kernel: [1053710.805174] RDX: 0000000000001000 RSI: 0000000001f9fe90 RDI: 000000000000000e 2021-07-07T16:24:41.803593+02:00 lena kernel: [1053710.805177] RBP: 0000000001f9fe90 R08: 0000000000000000 R09: 00007fff61dfbb30 2021-07-07T16:24:41.803594+02:00 lena kernel: [1053710.805180] R10: 0000000001a44440 R11: 0000000000000293 R12: 0000000000001000 2021-07-07T16:24:41.803596+02:00 lena kernel: [1053710.805182] R13: 00000000018442a0 R14: 0000000000001000 R15: 00007fc4b3c18700 ... This is with kernel: ... $ uname -a Linux lena 5.12.13-1-default #1 SMP Mon Jun 28 06:37:23 UTC 2021 (74bd8c0) x86_64 x86_64 x86_64 GNU/Linux ... It happens during a build and test run of gdb. I've updated and rebooted to kernel version 5.13.0-1-default, but ran into the same bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1166005] New: 20s to unlock fully encrypted partition
by bugzilla_noreply＠novell.com 25 Jan '23

25 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1166005 Bug ID: 1166005 Summary: 20s to unlock fully encrypted partition Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: axel.braun(a)gmx.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- I have a new TW installation with a 940GB encrypted root partition (including /boot, excluding /boot/efi). When starting the machine, grub asks in text mode for the passphrase. After entering the passphrase, it takes about 20s until the graphical boot screen appears. X1E:/home/test # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 953,9G 0 disk ├─nvme0n1p1 259:1 0 500M 0 part /boot/efi ├─nvme0n1p2 259:2 0 937G 0 part │ └─cr_root 254:0 0 937G 0 crypt / └─nvme0n1p3 259:3 0 16,4G 0 part [SWAP] linux:/home/test # cryptsetup luksDump /dev/nvme0n1p2 LUKS header information for /dev/nvme0n1p2 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 512 MK digest: c3 b3 b9 a1 4b cd 08 8d 93 47 59 be f1 b8 f3 24 5f ae 81 75 MK salt: 8b 87 eb c4 bd 43 4e af 57 ef eb 9f 3c 38 a9 8a f4 c5 63 2f 1b f6 98 1a 49 62 36 e0 9e 12 8a db MK iterations: 153840 UUID: 720864c9-f8ed-405e-9a17-ccfa1d2f347b Key Slot 0: ENABLED Iterations: 1229280 Salt: 5f 9b 38 6b 29 b4 2e b0 80 35 c5 bd 88 9f 77 61 29 6c 34 00 54 3c af a5 5a d4 f6 15 7e e4 8d c4 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED It is an i7-9750H machine, so CPU power should not be an issue... -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1184069] New: GRUB on a crypted partition takes > 10 seconds to unlock the filesystem
by bugzilla_noreply＠suse.com 25 Jan '23

25 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 Bug ID: 1184069 Summary: GRUB on a crypted partition takes > 10 seconds to unlock the filesystem Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: p.heinlein(a)heinlein-support.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I installed 15.2 plain vanilla on a Thinkpad X1.Extreme Gen.3 with a ~2 TB NVME and I set a crypto disc password during installation (in YaST). Grub needs > 10 seconds to unlock the key, so booting is very slow. It's very similar to https://unix.stackexchange.com/questions/369414/grub-takes-too-long-to-unlo… https://bbs.archlinux.org/viewtopic.php?id=228865 so I also think, that the crypto or number of iterations is way to expensive here and needs too much time. Maybe the SUSE team should/could look for a similar safe, but faster method (SHA256?) here? -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1190738] New: kernel-default-base does not contain kernel changelog
by bugzilla_noreply＠suse.com 25 Jan '23

25 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1190738 Bug ID: 1190738 Summary: kernel-default-base does not contain kernel changelog 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 CC: jeos-internal(a)suse.de Found By: --- Blocker: --- kernel-default-base is built from a separate set of .spec and .changes files, making use of the kernel-subpackage facilities. This however means that the changelog of the original kernel packages (kernel-default, -vanilla, etc.) does not end up in the changelog of kernel-default-base. This is especially visible in updates, which only change the binary content and the version number in an unobvious way. There is no mention of any relevant fixed bugs (bsc#, CVE-). It would be very useful to include the kernel changelog in the kernel-default-base package. I don't think it can (or should) be interleaved with the subpackage .changes file, but it could be included as file. The target systems usually have excludedocs enabled though, so marking the file as %doc means it won't get installed. That makes it more complex and annoying... -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1176026] New: bond interface should not invent mac address by default
by bugzilla_noreply＠suse.com 25 Jan '23

25 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1176026 Bug ID: 1176026 Summary: bond interface should not invent mac address by default 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: ro(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- since 5.8.4 (unsure about last digit): when setting up a bond if kernel chooses a random mac removing and readding the slave gets back to the used behaviour: obs-arm-1:~ # modprobe bonding 3: enP2p1s0v1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 1c:1b:0d:60:ee:8b brd ff:ff:ff:ff:ff:ff 7: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 9e:29:55:da:aa:0e brd ff:ff:ff:ff:ff:ff obs-arm-1:~ # echo +enP2p1s0v1 > /sys/class/net/bond0/bonding/slaves 7: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 9e:29:55:da:aa:0e brd ff:ff:ff:ff:ff:ff obs-arm-1:~ # echo -enP2p1s0v1 > /sys/class/net/bond0/bonding/slaves obs-arm-1:~ # echo +enP2p1s0v1 > /sys/class/net/bond0/bonding/slaves 7: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 1c:1b:0d:60:ee:8b brd ff:ff:ff:ff:ff:ff -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1190411] New: USB devices missing after kexec reboot with XHCI enabled
by bugzilla_noreply＠suse.com 25 Jan '23

25 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1190411 Bug ID: 1190411 Summary: USB devices missing after kexec reboot with XHCI enabled 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: roger.whittaker(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 852446 --> https://bugzilla.suse.com/attachment.cgi?id=852446&action=edit hwinfo, dmesg, usb-devices and lsusb with and without XHCI enabled in BIOS, normal boot and kexec boot Hardware is an Intel NUC (D54250WYK). With XHCI enabled in the UEFI BIOS, USB devices are not available after a kexec reboot. Hence the boot failed in the initrd when I had USB attached disks referenced in /etc/fstab. When I commented these out, the boot succeeded but the keyboard and mouse did not work after a kexec reboot. With XHCI disabled in the BIOS, kexec works as expected. On this hardware using Tumbleweed at some time in the past (but I'm afraid I don't know when) kexec worked with XHCI enabled. Linux jabberwock 5.14.0-1-default #1 SMP Mon Aug 30 07:01:36 UTC 2021 (dc06e24) x86_64 x86_64 x86_64 GNU/Linux NAME="openSUSE Tumbleweed" # VERSION="20210908" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20210908" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20210908" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed" LOGO="distributor-logo" -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1188589] New: libbpf: failed to find valid kernel BTF
by bugzilla_noreply＠suse.com 25 Jan '23

25 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1188589 Bug ID: 1188589 Summary: libbpf: failed to find valid kernel BTF 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: mrostecki(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since the update to the TW snapshot with the kernel 5.13.2-1, I see the following errors when trying to load BPF CO-RE skeletons with libbpf: libbpf: failed to find valid kernel BTF libbpf: Error loading vmlinux BTF: -3 The full example - I'm trying to load BPF programs which I have in this project: https://github.com/rancher-sandbox/lockc and the full output is: �� sudo ./out/lockcd libbpf: elf: skipping unrecognized data section(9) .rodata.str1.1 libbpf: failed to find valid kernel BTF libbpf: Error loading vmlinux BTF: -3 libbpf: failed to load object 'lockc_bpf' libbpf: failed to load BPF skeleton 'lockc_bpf': -3 Error: libbpf error Caused by: System error, errno: 3 Most likely, the solution for them would be setting the following kernel parameters to "y": CONFIG_DEBUG_INFO_REDUCED CONFIG_DEBUG_INFO_SPLIT But I'm not entirely sure yet. trying to test that... -- You are receiving this mail because: You are on the CC list for the bug.

1 9