April 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1222341] New: LCD Reboot will fail to connect to external monitor - Empty /sys edid files
by bugzilla_noreply＠suse.com 05 Apr '24

05 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222341 Bug ID: 1222341 Summary: LCD Reboot will fail to connect to external monitor - Empty /sys edid files Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel:Drivers Assignee: kernel-bugs(a)suse.de Reporter: monkeyboyted(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 874081 --> https://bugzilla.suse.com/attachment.cgi?id=874081&action=edit dmesg-2024-04-04-reboot On the LCD deck with official steam dock, reboot will fail to connect to the TV. TV - KDL-46Z5100 Sony Bravia Official Steam dock LCD Steam deck Steps to reproduce 1. Plug in the lcd steam deck with official dock 2. Plugin TV with HDMI 3. Reboot 4. The external screen will say no signal Information for package plasma6-mobile: --------------------------------------- Repository : openSUSE-Tumbleweed-Oss Name : plasma6-mobile Version : 6.0.3.1-1.1 Arch : x86_64 Vendor : openSUSE Installed Size : 5.8 MiB Installed : Yes Status : up-to-date Source package : plasma6-mobile-6.0.3.1-1.1.src Upstream URL : https://www.kde.org/ Summary : Plasma shell for mobile devices Description : Plasma shell for mobile devices. Operating System: openSUSE Tumbleweed 20240403 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-1-default (64-bit) Graphics Platform: Wayland Processors: 8 × AMD Custom APU 0405 Memory: 13.5 GiB of RAM Graphics Processor: AMD Custom GPU 0405 Manufacturer: Valve Product Name: Jupiter System Version: 1 Bios version - Version: F7A0120 Observations card1-Writeback-1 appears. Both card1-DP-1 and card1-Writeback-1 are empty edid files. ``` find /sys -name edid /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1/card1-Writeback-1/edid /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1/card1-eDP-1/edid /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1/card1-DP-1/edid ``` ``` [ 43.768121] amdgpu 0000:04:00.0: [drm] enabling link 1 failed: 15 ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1202296] Keyboard layout switcher applet and shortcut lost on logout
by bugzilla_noreply＠suse.com 05 Apr '24

05 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1202296 https://bugzilla.suse.com/show_bug.cgi?id=1202296#c3 Tristan Miller <psychonaut(a)nothingisreal.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Tristan Miller <psychonaut(a)nothingisreal.com> --- No longer reproducible for me now (with openSUSE Leap 15.5) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222345] New: Laptop wakes from suspend once the user closes the lid
by bugzilla_noreply＠suse.com 05 Apr '24

05 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222345 Bug ID: 1222345 Summary: Laptop wakes from suspend once the user closes the lid Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: psychonaut(a)nothingisreal.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I have a ThinkPad T14 Gen 4, which has an AMD Ryzen 7 PRO 7840U. With kernel-default 6.8.4-rc1, the computer can be suspended when the lid is open, but it wakes up as soon as the user closes the lid. The problem does not occur with kernel-default 5.14.21. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222156] radeon: After an upgrade the graphical interface no longer works
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222156 https://bugzilla.suse.com/show_bug.cgi?id=1222156#c36 --- Comment #36 from t neo <tneo(a)gmx.com> --- You can check the slow-roll repo and get Mesa 23 from there. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222344] New: gdb just getting stuck multiple minutes in silence when loading symbols(?) is very counter-intuitive
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222344 Bug ID: 1222344 Summary: gdb just getting stuck multiple minutes in silence when loading symbols(?) is very counter-intuitive Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: el(a)horse64.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I tried gdb for the first time to poke around firefox, and it was bit of an experience. A confusing hiccup always happens when having the symbols available and attaching to firefox (if I recall right the problem didn't show before I had downloaded the symbols so it's probably related to loading the symbols somehow): EXPECTED BEHAVIOR: gdb either is fast, or prints out what it does. No progress info needed, just a little "Loading up symbols, this is taking longer than usual..." or whatever it's even doing would be useful. ACTUAL BEHAVIOR: gdb will just get stuck without any sort of printed out line what it does or why or how long, and not react for like, 5 minutes or something extreme. The problem is that this is completely indistinguishable from the program just running, so naturally I'm inclined to hit CTRL+C except now that's a bad idea and doesn't just pause the program. This leads to a very confusing startup experience. Is this something specific with openSUSE's gdb, a bug or a feature, or is this a general gdb upstream issue? Sould I forward this request somewhere? AFFECTED VERSION: GNU gdb (GDB; openSUSE Slowroll) 13.2 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222338] curl 8.7.1 and libzypp cause curl error 92 on fetching updates
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222338 https://bugzilla.suse.com/show_bug.cgi?id=1222338#c2 Georg Pfuetzenreuter <georg.pfuetzenreuter(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |georg.pfuetzenreuter(a)suse.c | |om --- Comment #2 from Georg Pfuetzenreuter <georg.pfuetzenreuter(a)suse.com> --- I just tried this out of curiosity, and it seems to work: ``` $ podman run --rm --pull=always -it opensuse/tumbleweed 7fe8f2c44dad:/ # tee /etc/zypp/repos.d/chrome.repo <<EOF > [google-chrome] > enabled=1 > autorefresh=1 > baseurl=https://dl.google.com/linux/chrome/rpm/stable/x86_64 > gpgcheck=1 > EOF ... 7fe8f2c44dad:/ # zypper ref Looking for gpg key ID 9B30ACF2 in cache /var/cache/zypp/pubkeys. Repository google-chrome does not define additional 'gpgkey=' URLs. Warning: File 'repomd.xml' from repository 'google-chrome' is signed with an unknown key 'E88979FB9B30ACF2'. Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the whole repo. Warning: We can't verify that no one meddled with this file, so it might not be trustworthy anymore! You should not continue unless you know it's safe. File 'repomd.xml' from repository 'google-chrome' is signed with an unknown key 'E88979FB9B30ACF2'. Continue? [yes/no] (no): yes Retrieving repository 'google-chrome' metadata ....................[done] Building repository 'google-chrome' cache .........................[done] Retrieving repository 'openSUSE-Tumbleweed-Non-Oss' metadata ......[done] Building repository 'openSUSE-Tumbleweed-Non-Oss' cache ...........[done] Retrieving repository 'Open H.264 Codec (openSUSE Tumbleweed)' metadata [done] Building repository 'Open H.264 Codec (openSUSE Tumbleweed)' cache [done] Retrieving repository 'openSUSE-Tumbleweed-Oss' metadata ..........[done] Building repository 'openSUSE-Tumbleweed-Oss' cache ...............[done] Retrieving repository 'openSUSE-Tumbleweed-Update' metadata .......[done] Building repository 'openSUSE-Tumbleweed-Update' cache ............[done] All repositories have been refreshed. 7fe8f2c44dad:/ # rpm -q curl curl-8.7.1-1.1.x86_64 7fe8f2c44dad:/ # rpm -q libzypp libzypp-17.32.2-1.1.x86_64 ``` No occurrences of the mentioned error in zypper.log either. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222224] devel:languages:lua is building for outdated SLE_12_SP5 but not 15.6
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222224 https://bugzilla.suse.com/show_bug.cgi?id=1222224#c1 Matej Cepl <mcepl(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Matej Cepl <mcepl(a)suse.com> --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222342] New: gdb history seems almost entirely broken
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222342 Bug ID: 1222342 Summary: gdb history seems almost entirely broken Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: el(a)horse64.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- For some reason, the gdb history seems almost entirely broken. This might be a user error, but then maybe it would be worth poking upstream about making this somehow more obvious. EXPECTED BEHAVIOR: I do whatever in gdb for whatever amount of time. Then I use "quit". Then I relaunch it. All the commands I used before should show up when I press up arrow. I don't really care if the order is messed up or if there are duplicates or not, as long as the commands come back in full. ACTUAL BEHAVIOR: Whenever I use set history save on, I get one of these random things when I launch gdb later: 1. suddenly, the history only has half the commands I used in the previous session, or 2. it works (kind of rare), or 3. the entire history is nuked. What I get seems entirely random, but it's almost impossible to just get the history to work. AFFECTED VERSION: GNU gdb (GDB; openSUSE Slowroll) 13.2 ADDITIONAL INFO: I'm also using the mozilla symbols.py gdb script ( https://gist.github.com/luser/193572147c401c8a965c#file-symbols-py ) in case that somehow interferes with history. If it does and this is a mozilla problem let me know, I really wouldn't know. I usually use gdb UIs that don't really rely on gdb's own history saving. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222186] VirtualBox not allowed to access USB devices although user is in vboxusers group
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222186 https://bugzilla.suse.com/show_bug.cgi?id=1222186#c29 --- Comment #29 from Claudio Marcial Peon <claudio(a)datacor.net.ar> --- Confirmed. Updating to 20240402 fix the issue permanently. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1222313] btrfs storage discrepancy between used and free space of about 1/3 of the total disk capacity
by bugzilla_noreply＠suse.com 04 Apr '24

04 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222313 https://bugzilla.suse.com/show_bug.cgi?id=1222313#c11 Wenruo Qu <wqu(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix.niederwanger(a)suse.com | |, wqu(a)suse.com Flags| |needinfo?(felix.niederwange | |r(a)suse.com) --- Comment #11 from Wenruo Qu <wqu(a)suse.com> --- If you have some random IO workload, it's very possible that btrfs bookend extents are causing the problem. Furthermore, if you have truncated files (which is previously very large or preallocated), it can also take tons of unexpected space. Another point is, preallocation (falloc) is very btrfs unfriendly, if you have something like VM images, you'd be much better disable the snapshot of that subvolume, and set NOCOW flag for them. But since you have snapshots, the normal way to solve the problem (defrag) is not suitable as it would break the shared extents and cause extra space usage. It's recommended to delete all the unnecessary snapshots, and try "btrfs fi defrag" to see if it help (needs a sync after full defrag). Although there is a limitation on defrag that truncated files may not be that well defragged. If regular defrag (after deleting all snapshots) is not helping, you may want to try the following patches: - kernel part to enhance defrag: https://lore.kernel.org/linux-btrfs/cover.1710213625.git.wqu@suse.com/ - btrfs-progs support https://lore.kernel.org/linux-btrfs/cover.1710214834.git.wqu@suse.com/ -- You are receiving this mail because: You are on the CC list for the bug.

1 0