August 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1217749] New: No bass in built-in speakers on Lenovo Slim 7 16" AMD
by bugzilla_noreply＠suse.com 26 Oct '24

26 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1217749 Bug ID: 1217749 Summary: No bass in built-in speakers on Lenovo Slim 7 16" AMD Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: variable_valuables761(a)simplelogin.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 871116 --> https://bugzilla.suse.com/attachment.cgi?id=871116&action=edit Output of "hwinfo --sound" for Lenovo 16ARH7 It seems the bass speakers do not work in the latest Tumbleweed KDE snapshot on the Lenovo Slim 7 16" AMD, 16ARH7, 82UX0001US (and this same model is called Yoga outside the United States). This issue appears to be similar to that of the wide range of recently released laptops that have the CS35L41 and TAS2781 amps, however I cannot find that hardware listed in any of my logs or online spec sheets for this laptop. The closest I can find is that is has a Realtek ALC3287 codec. Attached is the output of "hwinfo --sound" Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1229020] New: Zypper dup installed kernels which reboot immediately
by bugzilla_noreply＠suse.com 25 Oct '24

25 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229020 Bug ID: 1229020 Summary: Zypper dup installed kernels which reboot immediately Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: wwonko(a)rdwarf.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876574 --> https://bugzilla.suse.com/attachment.cgi?id=876574&action=edit Screenshot before reboot. I’m running Tumbleweed, and when I ran a zypper dup I got new kernels, as expected. The new kernel won’t boot. It gets into the boot sequence, then does a hard boot shortly after the kernel starts to load. This happens with kernels 6.6.11-1-default and 6.9.7-1-default. My older kernel 6.5.4-1-default still boots correctly. I captured a screenshot of the boot failing. It pauses here for a second, and then hard boots. The forums said here was the best place to get a resolution for this. Please help! -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1229745] New: [Build 20240825] dbus-broker: no network after switchjing from NM to wicked
by bugzilla_noreply＠suse.com 25 Oct '24

25 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229745 Bug ID: 1229745 Summary: [Build 20240825] dbus-broker: no network after switchjing from NM to wicked Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/4434925/modules/prep are_test_data/steps/13 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation We have a few tests, that install a default GNOME setup (based on NetworkManager), then switch to wicked: After wicked has been started, the network stack seems not to be operational though openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-yast2_ui_devel@64bit fails in [prepare_test_data](https://openqa.opensuse.org/tests/4434925/modules/prepar… ## Test suite description Maintainer: zluo yast2 upstream test suites. https://progress.opensuse.org/issues/20206 ## Reproducible Fails since (at least) Build [20240825](https://openqa.opensuse.org/tests/4433680) ## Expected result Last good: [20240823](https://openqa.opensuse.org/tests/4430444) (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 on the CC list for the bug.

1 16

[Bug 1229555] New: Wicked dummy interfaces no longer come up / "no-device"
by bugzilla_noreply＠suse.com 25 Oct '24

25 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229555 Bug ID: 1229555 Summary: Wicked dummy interfaces no longer come up / "no-device" Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: georg.pfuetzenreuter(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876866 --> https://bugzilla.suse.com/attachment.cgi?id=876866&action=edit asgard2.i.o.o journal after boot Hi, we have various interfaces of type `dummy` configured on our openSUSE infrastructure firewall VMs, so far with no issues. They are all configured equally, here is one example: ``` # more /etc/sysconfig/network/ifcfg-d-os-code # ... comments ... STARTMODE='auto' BOOTPROTO='none' INTERFACETYPE='dummy' ``` Since installing updates and rebooting today, they no longer come up (neither automatically nor manually through ifup), returning "no-device". I will attach some information which I hope is useful .. .. from after boot: - `journalctl` .. from after enabling WICKED_DEBUG=all/WICKED_LOG_LEVEL=debug and restarting wickedd: - `wicked --debug all ifup d-os-code` # again just one example interface - `wicked show-config` - `wicked ifstatus --verbose all` - `grep 2024-08-21 /var/log/zypp/history` Let me know if anything of interest is missing. Would appreciate any ideas! I'm reluctant to update the second machine in the pair with this issue. There is another (presumably kernel) issue after the update, which I think is not related and hence reported separately at https://bugzilla.opensuse.org/show_bug.cgi?id=1229552. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1225352] New: [Build 13.199] openQA test fails in prepare_firstboot: RPi3 not booting?
by bugzilla_noreply＠suse.com 25 Oct '24

25 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1225352 Bug ID: 1225352 Summary: [Build 13.199] openQA test fails in prepare_firstboot: RPi3 not booting? Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://openqa.opensuse.org/tests/4217406/modules/prep are_firstboot/steps/1 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Live Medium Assignee: fvogt(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: --- The Leap 15.5 JeOS image fails to boot in openQA for some time now. Initially it looked to me like an issue with the test infra, but the TW and 15.6 images boot while 15.5 fails consistently. I tried to reproduce the issue locally and except for a slow boot due to no ethernet cable it worked. The package diff between last working and latest build shows changes in aaa_base, coreutils, kernel, less, protobuf, libsemanage, perl, rpm and yast. Could be a kernel issue? ## Observation openQA test in scenario opensuse-15.5-JeOS-for-RPi-aarch64-jeos@RPi3 fails in [prepare_firstboot](https://openqa.opensuse.org/tests/4217406/modules/prepar… ## Test suite description Maintainer: fvogt, mnowak Start JeOS from the HDD image, configure it using the firstboot wizard and then run basic tests. console=tty0 added as needed for aarch64. ## Reproducible Fails since (at least) Build [13.183](https://openqa.opensuse.org/tests/4120363) ## Expected result Last good: [13.182](https://openqa.opensuse.org/tests/4119085) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are on the CC list for the bug.

1 48

[Bug 1228383] New: 'No free space in /boot/efi for new kernel' error during dist-upgrade
by bugzilla_noreply＠suse.com 25 Oct '24

25 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1228383 Bug ID: 1228383 Summary: 'No free space in /boot/efi for new kernel' error during dist-upgrade Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: v.jag(a)mailbox.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 876303 --> https://bugzilla.suse.com/attachment.cgi?id=876303&action=edit Zypper dup log During the zypper dup to install 20240725 snapshot i got the following error: “Error: No free space in /boot /efi for new kernel" After reboot PC failed to boot into GUI so i had to rollback to previous snapshot. Zypper output log is attached separately. userv@localhost:~> grep LOADER_TYPE /etc/sysconfig/bootloader LOADER_TYPE="grub2-efi" userv@localhost:~> ls -lR /boot/efi /boot/efi: total 6 drwxr-xr-x 4 root root 2048 Oct 30 2022 EFI drwxr-xr-x 3 root root 2048 Jul 27 12:01 loader drwxr-xr-x 6 root root 2048 Jul 27 16:42 opensuse-tumbleweed /boot/efi/EFI: total 4 drwxr-xr-x 2 root root 2048 Jul 27 12:01 boot drwxr-xr-x 3 root root 2048 Jul 27 12:01 opensuse /boot/efi/EFI/boot: total 3880 -rwxr-xr-x 1 root root 934024 Jul 27 19:16 BOOTX64.EFI -rwxr-xr-x 1 root root 86208 Mar 14 07:58 fallback.efi -rwxr-xr-x 1 root root 155 Jul 27 19:16 grub.cfg -rwxr-xr-x 1 root root 2099056 Jul 27 19:16 grub.efi -rwxr-xr-x 1 root root 846096 Jul 27 19:16 MokManager.efi /boot/efi/EFI/opensuse: total 4124 -rwxr-xr-x 1 root root 64 Jul 27 12:01 boot.csv -rwxr-xr-x 1 root root 155 Jul 30 2023 grub.cfg -rwxr-xr-x 1 root root 2099056 Jul 19 12:59 grub.efi -rwxr-xr-x 1 root root 331776 Jul 27 19:16 grubx64.efi -rwxr-xr-x 1 root root 20 Jul 27 12:01 installed_by_sdbootutil -rwxr-xr-x 1 root root 846096 Mar 14 07:58 MokManager.efi -rwxr-xr-x 1 root root 934024 Mar 14 07:58 shim.efi drwxr-xr-x 2 root root 2048 Mar 30 16:58 x86_64-efi /boot/efi/EFI/opensuse/x86_64-efi: total 4 -rwxr-xr-x 1 root root 3904 Jul 19 12:59 bli.mod /boot/efi/loader: total 4 drwxr-xr-x 2 root root 2048 Mar 30 16:58 entries -rwxr-xr-x 1 root root 32 Jul 27 12:01 random-seed /boot/efi/loader/entries: total 0 /boot/efi/opensuse-tumbleweed: total 8 drwxr-xr-x 2 root root 2048 Jul 30 2023 6.0.5-1-default drwxr-xr-x 2 root root 2048 Jul 27 16:41 6.4.11-1-default drwxr-xr-x 2 root root 2048 Jul 28 09:43 6.9.6-1-default drwxr-xr-x 2 root root 2048 Jul 27 11:54 6.9.9-1-default /boot/efi/opensuse-tumbleweed/6.0.5-1-default: total 0 /boot/efi/opensuse-tumbleweed/6.4.11-1-default: total 0 /boot/efi/opensuse-tumbleweed/6.9.6-1-default: total 0 /boot/efi/opensuse-tumbleweed/6.9.9-1-default: total 0 I'm discussing this issue on openSUSE forums https://forums.opensuse.org/t/no-free-space-in-boot-efi-for-new-kernel-erro… arvidjaar stated that "They attempt to use sdbootutil even though the system is setup to use grub2-efi." -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1225296] New: Dual monitor not recognised after upgrade 15.5 to 15.6
by bugzilla_noreply＠suse.com 24 Oct '24

24 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1225296 Bug ID: 1225296 Summary: Dual monitor not recognised after upgrade 15.5 to 15.6 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: martin.schmidt(a)io-warnemuende.de QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Moin, moin, I am using openSUSE 15.5 on an old intel based x86 PC, equipped with a simple nvidia gforce and two monitors. The monitors are using a displayport connnection from the graphics card to the monitors via an Y-shaped cable. Both monitors are recognised correctly and can be configured to form a single graphical work space, when the system is up and running. After upgrading to openSUSE 15.6 this does not work any more. When booting, monitor 1 shows some firmware screen and the openSUSE boot screen, where the OS version (several subversions of 15.6 and frozen snapshots of 15.5) can be selected. Using the default option (15.6 from harddrive), the output of the boot process is moving to monitor 2, but monitor 1 is going to a "power saving sleep mode" and stays inactive frome here on. The boot process is finished correctly with monitor 2 as the only graphical device. Monitor 1 cannot be activated again. Switching off monitor 2 before booting, the system comes up without any valid output device. Monitor 1 goes to sleep after the system boot started. I did not check the system status with a remote ssh-connection yet. Switching off monitor 1 before booting, lets the system come up completely with monitor 2. Also the initial hardware screen is diplayerd there. In turn, booting from a read-only snapshot with openSUSE 15.5, both monitors are used as before. The nouveau-dri drivers are used, no propriatary nvidia driver is installed. Some upgrade history: - just to test, if the few graphic card cores could be used in a cuda environment, cuda was installed under 15.5. This failed and cuda was deinstalled. However, when upgrading later from 15.5 to 15.6 the cuda development environment was reinstalled automatically together with nvidia drivers. As a result the nvidia drivers allowed only for a single low resolution vga monitor. May be, this happened, since the nvidia repository was not deleted and there was some leftover from the cuda test. - with the ascii-yast the nvidia drivers (gforce003/004) and cuda could be removed and the nouveau-dri drivers where reinstalled - together with dependencies. This allows for a single monitor OS_15.6 system with high resolution, but the second monitor (monitor 1) is lost during the boot process as described above. Before I try to install from scratch just with the hope that the error goes away, I am reporting this strange behaviour here. May be, this helps to streamline the distribution. Any hints are very welcome - especially how to modify the bootloader options. Cheers, Martin Schmidt -- You are receiving this mail because: You are on the CC list for the bug.

1 31

[Bug 1229678] New: VUL-0: CVE-2024-45192: element-web: olm: use of base64 when decoding group session keys can lead to successful cache-timing attacks
by bugzilla_noreply＠suse.com 24 Oct '24

24 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229678 Bug ID: 1229678 Summary: VUL-0: CVE-2024-45192: element-web: olm: use of base64 when decoding group session keys can lead to successful cache-timing attacks Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/418589/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: dheidler(a)suse.com Reporter: camila.matos(a)suse.com QA Contact: security-team(a)suse.de CC: camila.matos(a)suse.com, cunix(a)mail.de, marius.kittler(a)suse.com, okurz(a)suse.com, security-team(a)suse.de, smash_bz(a)suse.de Blocks: 1229676 Target Milestone: --- Found By: Security Response Team Blocker: --- +++ This bug was initially created as a clone of Bug #1229676 +++ An issue was discovered in Matrix libolm (aka Olm) through 3.2.16. Cache-timing attacks can occur due to use of base64 when decoding group session keys. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. References: https://gitlab.matrix.org/matrix-org/olm/ https://gitlab.matrix.org/matrix-org/olm/-/commit/6d4b5b07887821a95b144091c… https://news.ycombinator.com/item?id=41249371 https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45192 https://www.cve.org/CVERecord?id=CVE-2024-45192 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1229676] New: VUL-0: CVE-2024-45192: TRACKERBUG: olm: use of base64 when decoding group session keys can lead to successful cache-timing attacks
by bugzilla_noreply＠suse.com 24 Oct '24

24 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229676 Bug ID: 1229676 Summary: VUL-0: CVE-2024-45192: TRACKERBUG: olm: use of base64 when decoding group session keys can lead to successful cache-timing attacks Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/418589/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: cunix(a)mail.de Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: camila.matos(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- An issue was discovered in Matrix libolm (aka Olm) through 3.2.16. Cache-timing attacks can occur due to use of base64 when decoding group session keys. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. References: https://gitlab.matrix.org/matrix-org/olm/ https://gitlab.matrix.org/matrix-org/olm/-/commit/6d4b5b07887821a95b144091c… https://news.ycombinator.com/item?id=41249371 https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45192 https://www.cve.org/CVERecord?id=CVE-2024-45192 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1229237] New: games:tools/Bottles: Cursor Size Issue
by bugzilla_noreply＠suse.com 23 Oct '24

23 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229237 Bug ID: 1229237 Summary: games:tools/Bottles: Cursor Size Issue Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Minor Priority: P5 - None Component: 3rd party software Assignee: vortex(a)z-ray.de Reporter: reiokorn(a)tutanota.com QA Contact: screening-team-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When using the Bottles application on openSUSE Tumbleweed (build 20240813) with a display scaling setting above 100%, the cursor size within the GUI becomes excessively large. This issue only occurs under Wayland with scaling enabled. System Information: OS: openSUSE Tumbleweed 20240813 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.3-1-default (64-bit) Graphics Platform: Wayland Steps to Reproduce: Set display scaling to above 100% in KDE Plasma on Wayland. Launch the Bottles application. Expected Result: The cursor should maintain a consistent size relative to other GUI elements within the application. Actual Result: The cursor size becomes abnormally large when hovering over the Bottles GUI, disrupting the user experience. Terminal Output: Relevant warnings observed during application launch: Gdk-WARNING **: ../gdk/wayland/gdkcursor-wayland.c:210 cursor image size (64) not an integer multiple of theme size (24) This warning is repeated multiple times with different cursor image sizes. -- You are receiving this mail because: You are on the CC list for the bug.

1 7