October 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1204045] New: /usr/lib/plymouth/plymouth-populate-initrd: line 450: +: command not found
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1204045 Bug ID: 1204045 Summary: /usr/lib/plymouth/plymouth-populate-initrd: line 450: +: command not found Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: dheidler(a)suse.com QA Contact: qa-bugs(a)suse.de CC: qzhao(a)suse.com Found By: --- Blocker: --- dracut: *** Including module: systemd-initrd *** dracut: *** Including module: i18n *** dracut: *** Including module: drm *** dracut: *** Including module: plymouth *** /usr/lib/plymouth/plymouth-populate-initrd: line 450: +: command not found There seems to be just a "+" in that line. Looks like a fragment of a wrongly applied patch. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1203147] dracut reports: /usr/lib/plymouth/plymouth-populate-initrd: line 450: +: command not found
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1203147 https://bugzilla.suse.com/show_bug.cgi?id=1203147#c4 Cliff Zhao <qzhao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Cliff Zhao <qzhao(a)suse.com> --- Close as the fix has been accepted. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203147] dracut reports: /usr/lib/plymouth/plymouth-populate-initrd: line 450: +: command not found
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1203147 https://bugzilla.suse.com/show_bug.cgi?id=1203147#c3 Cliff Zhao <qzhao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dheidler(a)suse.com --- Comment #3 from Cliff Zhao <qzhao(a)suse.com> --- *** Bug 1204045 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204152] New: X11:Drivers:Video/nvidia-gfxG06: Update needed
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1204152 Bug ID: 1204152 Summary: X11:Drivers:Video/nvidia-gfxG06: Update needed Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: sndirsch(a)suse.com Reporter: Mathias.Homann(a)opensuse.org QA Contact: screening-team-bugs(a)suse.de Found By: --- Blocker: --- Please upgrade to 515.76 soon, the latest available version does not build with TW 20221006 / Kernel 6.0.0 (See fatory list and https://rglinuxtech.com/?p=3060 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1203340] New: AUDIT-0: sendmail: Need to crate /run/sendmail
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203340 Bug ID: 1203340 Summary: AUDIT-0: sendmail: Need to crate /run/sendmail Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Current SR#990515 had been declined due to sendmail.x86_64: E: systemd-tmpfile-entry-unauthorized (Badness: 10) /usr/lib/tmpfiles.d/sendmail.conf "a+ /run - - - - u:mail:rwx,g:mail:rwx" sendmail.x86_64: E: systemd-tmpfile-entry-unauthorized (Badness: 10) /usr/lib/tmpfiles.d/sendmail.conf "a+ /run/sendmail - - - - u:mail:rwx,g:mail:rwx" This package installs a systemd-tmpfiles drop-in configuration file that contains sensitive configuration entries. If the package is intended for inclusion in any SUSE product please open a bug report to request review of the package by the security team. Please refer to https://en.opensuse.org/openSUSE:Package_security_guidelines#audit_bugs for more information. but current package throws warnings during starting its services therefore this changes seems to be required -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1203718] New: USB/UAS device resets happening with external SATA III 6G HDD enclosure
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203718 Bug ID: 1203718 Summary: USB/UAS device resets happening with external SATA III 6G HDD enclosure 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: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: eecdc3.opensuse(a)coders-haven.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Dear openSUSE community, I am unfortunately experiencing frequent USB/UAS device resets with my new FANTEC DB-ALU31, which according to its product name (ASM235) is using an ASM235CM chipset from ASMedia. The relevant output from `lsusb -vt` is as follows: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M ID 0bda:0423 Realtek Semiconductor Corp. |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=uas, 10000M ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge The device is detected and can be mounted without issues but during regular use it may slow down or freeze programs that try to access it with output in /var/log/messages looking like: 2022-09-24T10:16:25.112084+02:00 kernel: [ 6192.198327][T26507] sd 0:0:0:0: [sda] tag#14 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT 2022-09-24T10:16:25.112102+02:00 kernel: [ 6192.198336][T26507] sd 0:0:0:0: [sda] tag#14 CDB: Write(16) 8a 00 00 00 00 02 46 07 2f 5f 00 00 00 18 00 00 2022-09-24T10:16:25.112104+02:00 kernel: [ 6192.198492][T26507] sd 0:0:0:0: [sda] tag#13 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT 2022-09-24T10:16:25.112106+02:00 kernel: [ 6192.198498][T26507] sd 0:0:0:0: [sda] tag#13 CDB: Write(16) 8a 00 00 00 00 02 46 07 2f 37 00 00 00 28 00 00 2022-09-24T10:16:25.112108+02:00 kernel: [ 6192.198644][T26507] sd 0:0:0:0: [sda] tag#12 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT 2022-09-24T10:16:25.112109+02:00 kernel: [ 6192.198650][T26507] sd 0:0:0:0: [sda] tag#12 CDB: Write(16) 8a 00 00 00 00 02 46 07 2f 17 00 00 00 20 00 00 2022-09-24T10:16:25.112111+02:00 kernel: [ 6192.198800][T26507] sd 0:0:0:0: [sda] tag#11 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT 2022-09-24T10:16:25.112126+02:00 kernel: [ 6192.198806][T26507] sd 0:0:0:0: [sda] tag#11 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e f7 00 00 00 20 00 00 2022-09-24T10:16:25.112127+02:00 kernel: [ 6192.198943][T26507] sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT 2022-09-24T10:16:25.112128+02:00 kernel: [ 6192.198949][T26507] sd 0:0:0:0: [sda] tag#10 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e e7 00 00 00 10 00 00 2022-09-24T10:16:25.112129+02:00 kernel: [ 6192.199094][T26507] sd 0:0:0:0: [sda] tag#9 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT 2022-09-24T10:16:25.112130+02:00 kernel: [ 6192.199101][T26507] sd 0:0:0:0: [sda] tag#9 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e c7 00 00 00 20 00 00 2022-09-24T10:16:25.112130+02:00 kernel: [ 6192.199278][T26507] sd 0:0:0:0: [sda] tag#8 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT 2022-09-24T10:16:25.112131+02:00 kernel: [ 6192.199285][T26507] sd 0:0:0:0: [sda] tag#8 CDB: Write(16) 8a 00 00 00 00 02 46 07 2e bf 00 00 00 08 00 00 2022-09-24T10:16:25.112133+02:00 kernel: [ 6192.199393][T26507] sd 0:0:0:0: [sda] tag#7 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN 2022-09-24T10:16:25.112134+02:00 kernel: [ 6192.199397][T26507] sd 0:0:0:0: [sda] tag#7 CDB: Read(16) 88 00 00 00 00 02 06 96 c9 d8 00 00 00 07 00 00 2022-09-24T10:16:25.112135+02:00 kernel: [ 6192.200510][T26507] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 2022-09-24T10:16:25.112136+02:00 kernel: [ 6192.200513][T26507] sd 0:0:0:0: [sda] tag#6 CDB: Read(16) 88 00 00 00 00 02 06 96 c5 df 00 00 03 f9 00 00 2022-09-24T10:16:25.116046+02:00 kernel: [ 6192.204015][T26507] sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN 2022-09-24T10:16:25.116063+02:00 kernel: [ 6192.204022][T26507] sd 0:0:0:0: [sda] tag#5 CDB: Read(16) 88 00 00 00 00 02 06 96 cd d8 00 00 00 07 00 00 2022-09-24T10:16:25.120123+02:00 kernel: [ 6192.207464][T26507] sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN 2022-09-24T10:16:25.120131+02:00 kernel: [ 6192.207472][T26507] sd 0:0:0:0: [sda] tag#4 CDB: Read(16) 88 00 00 00 00 02 06 96 c9 df 00 00 03 f9 00 00 2022-09-24T10:16:25.148038+02:00 kernel: [ 6192.234339][T25745] scsi host0: uas_eh_device_reset_handler start 2022-09-24T10:16:25.228043+02:00 kernel: [ 6192.314872][T25745] usb 4-1.3: reset SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd 2022-09-24T10:16:25.248055+02:00 kernel: [ 6192.337003][T25745] scsi host0: uas_eh_device_reset_handler success After I added a quirk to /etc/modprobe.d/ via 'options usb-storage quirks=174c:55aa:u' to ignore UASP support, the occurrance rate of the resets seems to have reduced but they still occur: 2022-09-24T10:52:44.552258+02:00 kernel: [ 545.639051][ T3616] usb 4-1.3: reset SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd 2022-09-24T10:52:44.572116+02:00 kernel: [ 545.660702][ C1] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s 2022-09-24T10:52:44.572139+02:00 kernel: [ 545.660715][ C1] sd 0:0:0:0: [sda] tag#0 CDB: Read(16) 88 00 00 00 00 01 f4 f4 1a 37 00 00 07 f9 00 00 2022-09-24T10:52:44.572143+02:00 kernel: [ 545.660719][ C1] blk_update_request: I/O error, dev sda, sector 8404605495 op 0x0:(READ) flags 0x84700 phys_seg 29 prio class 0 I am using an up-to-date installation of openSUSE Leap 15.4 running Linux 5.14.21-150400.24.21-default and any help debugging this further will be appreciated. (The fact that the device string shown by `lsusb` makes no mention of the updated chipset leads me to believe that support for this chipset has not hit the kernel yet, but I am not familiar with the USB kernel driver nor with debugging it.) Note that I have already checked the S.M.A.R.T. attributes and there does not appear to be a problem with the device itself. I can also use the device without problems with Windows 10 21H2, even after extended use. Thanks in advance for your assistance! -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1179634] If X2Go server uses KDE the X2Go client can not connect - Error message -Can not start KDE
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1179634 https://bugzilla.suse.com/show_bug.cgi?id=1179634#c2 --- Comment #2 from Krasimir Ivanov <kiv(a)mail.orbitel.bg> --- The solution of this problem I found is very simple. Since some time KDE is started by new command to start plasma. This command need to be set in to X2Go and it will work properly again. Now as workaround people are enforced to setup X2Go with the option for unknown distribution and there put this command. Same happen with the xrdp. There your script which is coming from openSUSE does not work with KDE and xrdp can not start KDE. My solution for xrdp is as follows: In order for xRDP work sessions in openSUSE and SUSE to work with KDE, you need to make three changes to the /etc/xrdp/startwm.sh file 1. Find SESSION="gnome" and change it to SESSION="plasma" 2. We find export XDG_SESSION_TYPE=x11 and comment this line with # 3. We add a new line just below the one from point 2, with the following content: eval $(dbus-launch --sh-syntax) Then we save this file and after restarting xrdp, when logging in via RDP, it will open for us the KDE desktop environment. It will be nice if some one from openSUSE developers could check all such scripts prepared in past to start KDE and change them to start plasma. This will save a lot of effort for users who now have to redo the scripts they get from SUSE/openSUSE during the OS installation every install. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1202930] After install did not boot in graphic mode at Thinkpad T60 with Ati X1300. Need to install xf86-video-ati
by bugzilla_noreply＠suse.com 08 Oct '22

08 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202930 http://bugzilla.opensuse.org/show_bug.cgi?id=1202930#c10 --- Comment #10 from Felix Miata <mrmazda(a)earthlink.net> --- (In reply to Igor Kuznetsov from comment #9) > While installing openSUSE i did not deselect any packages. Only choose the > option install with plasma environment. Perhaps a change was made, but it used to be that selecting Plasma, without any customization of packages selection, would result in xorg-x11-driver-video being installed, which would install xf86-video-ati, which provides the Radeon display device driver required by your X1300. I haven't installed TW fresh on any old Radeon GPU in a long time, so would not have noticed a change. I mounted the TW DVD .iso from 20220925 just now to find the following: # ls -Gg /mnt/x86_64/xf86-video-ati-* -r--r--r-- 1 172459 Aug 31 22:34 xf86-video-ati-19.1.0-6.3.x86_64.rpm -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203363] [Build 277.3] openQA test fails in snapper_cleanup - quota rescan or sync failed
by bugzilla_noreply＠suse.com 07 Oct '22

07 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1203363 https://bugzilla.suse.com/show_bug.cgi?id=1203363#c4 --- Comment #4 from Wenruo Qu <wqu(a)suse.com> --- The dmesg is showing qgroup rescan is always running, and snapper_cleanup-dmesg.log is showing a lot of blocked workqueue. And the rescan of vda2 seems to be unexpectedly long, over 60s not finished. But without a full picture, hard to say if it's really hanging or something else (just scheduling/perf problem?) Is it possible to make snapper to wait for the running quota scan? For latest btrfs-progs, we have "btrfs quota scan -w" option to wait for the running one. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203363] [Build 277.3] openQA test fails in snapper_cleanup - quota rescan or sync failed
by bugzilla_noreply＠suse.com 07 Oct '22

07 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1203363 Goldwyn Rodrigues <rgoldwyn(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|rgoldwyn(a)suse.com |wqu(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0