April 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1197896] [Build 20220328] openQA test fails in yast2_samba
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197896 https://bugzilla.suse.com/show_bug.cgi?id=1197896#c1 Noel Power <nopower(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nopower(a)suse.com --- Comment #1 from Noel Power <nopower(a)suse.com> --- afaics the error really is at https://openqa.opensuse.org/tests/2275021#step/yast2_samba/78 where looking in the yast2 log it appears trying to start smbd (which fails to start) and in turn yast2-samba-server fails (giving the 'didn't finish err') [ 376.054804] smbd[4648]: smbd version 4.15.5-git.328.f1f29505d84SUSE-oS15.9-x86_64 started. [ 376.056333] smbd[4648]: Copyright Andrew Tridgell and the Samba Team 1992-2021 [ 376.088424] ns-slapd[4048]: [31/Mar/2022:12:44:32.818777214 -0400] - ERR - oc_check_allowed_sv - Entry "sambaDomainName=QA-SAMBA,dc=ldaptest,dc=org" -- attribute "sambaminpwdlength" not allowed [ 376.103658] smbd[4648]: [2022/03/31 12:44:32.832368, 0] ../../source3/passdb/pdb_ldap_util.c:320(smbldap_search_domain_info) [ 376.105120] smbd[4648]: smbldap_search_domain_info: Adding domain account policies for QA-SAMBA failed with NT_STATUS_UNSUCCESSFUL [ 376.115876] smbd[4648]: [2022/03/31 12:44:32.832465, 0] ../../source3/passdb/pdb_ldap.c:6779(pdb_ldapsam_init_common) [ 376.124389] systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE [ 376.125550] smbd[4648]: pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the domain. We cannot work reliably without it. [ 376.128861] systemd[1]: smb.service: Failed with result 'exit-code'. [ 376.129785] smbd[4648]: [2022/03/31 12:44:32.832501, 0] ../../source3/passdb/pdb_interface.c:181(make_pdb_method_name) [ 376.131479] systemd[1]: Failed to start Samba SMB Daemon. [ 376.132922] smbd[4648]: pdb backend ldapsam:ldap://localhost:389 did not correctly init (error was NT_STATUS_CANT_ACCESS_DOMAIN_INFO) [ 376.225062] dbus-daemon[615]: [system] Activating via systemd: service name='org.opensuse.Snapper' unit='snapperd.service' requested by ':1.92' (uid=0 pid=4653 comm="/usr/bin/snapper create --type=post --cleanup-algo") ns-slapd[4048]: [31/Mar/2022:12:44:32.818777214 -0400] - ERR - oc_check_allowed_sv - Entry "sambaDomainName=QA-SAMBA,dc=ldaptest,dc=org" -- attribute "sambaminpwdlength" not allowed is probably the real cause (but I confess I don't know where that comes from) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1091802] New: openldap2: incomplete macro expansion(?) in script
by bugzilla_noreply＠novell.com 01 Apr '22

01 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1091802 Bug ID: 1091802 Summary: openldap2: incomplete macro expansion(?) in script Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: GuoHouzuo(a)gmail.com Reporter: jengelh(a)inai.de QA Contact: qa-bugs(a)suse.de CC: mpluskal(a)suse.com, varkoly(a)suse.com Found By: --- Blocker: --- The following product is going to be upgraded: openSUSE Tumbleweed 20180427-0 -> 20180501-0 x86_64 base openSUSE (38/73) Installing: openldap2-2.4.46-33.1.x86_64 ...................................................[done] Additional rpm output: /usr/sbin/openldap_update_modules_path.sh: line 1: s: command not found Updating /etc/sysconfig/openldap ... -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1197808] New: workrave does not support GNOME 42
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1197808 Bug ID: 1197808 Summary: workrave does not support GNOME 42 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: tjyrinki(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- See upstream report at https://github.com/kgshank/gse-sound-output-device-chooser/issues/229 Metadata changing alone is not enough to fix the applet, so a couple of other patches are needed as well. I'm preparing a build. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1196681] AUDIT-WHITELIST: deepin: backport of whitelisting for Leap 15.4
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1196681 Wolfgang Frisch <wolfgang.frisch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197607] New: Bluetooth speaker has no volume control (sound full on)
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1197607 Bug ID: 1197607 Summary: Bluetooth speaker has no volume control (sound full on) 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: Sound Assignee: tiwai(a)suse.com Reporter: websl-osmat(a)vasten.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 857434 --> http://bugzilla.opensuse.org/attachment.cgi?id=857434&action=edit dmesg Not sure if this belongs in the "sound" or "bluetooth" categories. I'm running the MATE desktop. My laptop, previously installed with OpenSUSE 15.3, was upgraded using the approved upgrade process to 15.4 beta. All working as expected, except the paired bluetooth speaker. Bluetooth connects perfectly, but the speaker is at full volume. The mate volume control applet sliders have no effect on bluetooth speaker output. Volume control works perfectly with the built=in speaker. inxi -E Bluetooth: Device-1: Realtek Bluetooth Radio type: USB driver: btusb Report: bt-adapter ID: hci0 state: up address: 5C:3A:45:DC:9A:F6 inxi -A Audio: Device-1: Advanced Micro Devices [AMD/ATI] Renoir Radeon High Definition Audio driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel Sound Server-1: ALSA v: k5.14.21-150400.11-default running: yes Sound Server-2: PulseAudio v: 15.0 running: yes inxi -b System: Host: bumpkin Kernel: 5.14.21-150400.11-default x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Leap 15.4 Beta Machine: Type: Laptop System: HUAWEI product: NBLL-WXX9 v: M1030 serial: 87KPM20908000217 Mobo: HUAWEI model: NBLL-WXX9-PCB v: M1030 serial: PM13P02095001247 UEFI: HUAWEI v: 1.05 date: 07/20/2020 Battery: ID-1: BAT1 charge: 51.4 Wh (100.0%) condition: 51.4/54.9 Wh (93.5%) CPU: Info: 6-Core AMD Ryzen 5 4500U with Radeon Graphics [MCP] speed: 1397 MHz min/max: 1400/2375 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Device-2: Quanta ov9734_techfront_camera type: USB driver: uvcvideo Display: server: X.org 1.20.3 driver: loaded: amdgpu,ati unloaded: fbdev,modesetting,vesa tty: 132x40 Message: Advanced graphics data unavailable in console for root. Network: Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_8822ce Drives: Local Storage: total: 476.94 GiB used: 243.88 GiB (51.1%) Info: Processes: 257 Uptime: 0h 29m Memory: 7.13 GiB used: 2.17 GiB (30.4%) Init: systemd runlevel: 5 Shell: Bash inxi: 3.3.07 -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1196681] AUDIT-WHITELIST: deepin: backport of whitelisting for Leap 15.4
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1196681 https://bugzilla.suse.com/show_bug.cgi?id=1196681#c6 --- Comment #6 from Wolfgang Frisch <wolfgang.frisch(a)suse.com> --- Sorry for the long delay. I have since reviewed the changes since the last full audit (bsc#1070943), corresponding to dde-api versions 5.4.11...5.5.5. None of the privileged functions have been changed significantly, so we can proceed with the backport. >W: polkit-untracked-privilege com.deepin.api.device.unblock-bluetooth-devices https://github.com/openSUSE/polkit-default-privs/pull/73 >E: suse-dbus-unauthorized-service (Badness: 10000) /usr/share/dbus-1/system-services/com.deepin.api.Device.service >E: suse-dbus-unauthorized-service (Badness: 10000) /usr/share/dbus-1/system-services/com.deepin.api.LocaleHelper.service >E: suse-dbus-unauthorized-service (Badness: 10000) /usr/share/dbus-1/system-services/com.deepin.api.SoundThemePlayer.service https://build.opensuse.org/request/show/966385 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197625] grub-tpm.efi split still needed?
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197625 https://bugzilla.suse.com/show_bug.cgi?id=1197625#c7 --- Comment #7 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Michael Chang from comment #6) > (In reply to Fabian Vogt from comment #5) > > (In reply to Michael Chang from comment #4) > > > (In reply to Fabian Vogt from comment #3) > > > > (In reply to Michael Chang from comment #1) > > [snip] > > > Having the return code would be very helpful. > > > > In the thread there's the theory that appending the entry to the event log > > causes > > it to fail, which sounds likely. According to the spec, it would then return > > EFI_VOLUME_FULL, which is indeed not handled. This also explains why it only > > fails > > on snapshot boots (more commands to measure, which are all copied verbatim > > into the > > event log!) and why it gets worse on the second attempt. > > > > In the case of EFI_VOLUME_FULL, the correct behaviour is to log that and > > continue, > > as the measurement itself was successful. There's the option to retry with > > EFI_TCG2_EXTEND_ONLY to skip logging, but in the case of a previous > > EFI_VOLUME_FULL > > error that will be returned again (it's sticky!), so there's no point... > > If the whole point here is to log the error EFI_VOLUME_FULL and continue > execution as is, then it is not new to grub. I think there are other > occasions where (non critical) errors are handled this way. The problem is > do we have the hardware to verify it ? The original reporter might be available or if nobody is available for testing we could add the patch and wait for someone to complain... > Should we make such error handling a > common thing to all tpm's "unknown errors" ? No, that's potentially a security issue. > > > > I hit something related on my machine (boo#1165773), where the FW claimed to > > > > have a TPM event log without the TPM being enabled. > > > > > > Maybe such state can be reflect in EFI_TCG2_PROTOCOL.GetCapability ? It > > > seems testing tpm presence is not enough. > > > > It should be... > > My point is that whenever tpm is disabled, no measurement should be > performed hence users will not receive any errors related to tpm, otherwise > it is confusing. An enhancement can thus be made if the test can cover both > tpm presence and enablement and stop in advance. Yes, that should already be the case. If even with disabled TPM the protocol returns that it's present, that's a FW bug we can't do anything about. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197901] Asus BR1100CKA laggy touchpad after suspend
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197901 https://bugzilla.suse.com/show_bug.cgi?id=1197901#c5 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alextarasov362(a)gmail.com Flags| |needinfo?(alextarasov362@gm | |ail.com) --- Comment #5 from Takashi Iwai <tiwai(a)suse.com> --- In anyway, I'm building a test kernel with a downstream patch in OBS home:tiwai:bsc1197901 repo. It'll be available later at http://download.opensuse.org/repositories/home:/tiwai:/bsc1197901/standard/ Please check whether the bug persists with it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197625] grub-tpm.efi split still needed?
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1197625 https://bugzilla.suse.com/show_bug.cgi?id=1197625#c6 --- Comment #6 from Michael Chang <mchang(a)suse.com> --- (In reply to Fabian Vogt from comment #5) > (In reply to Michael Chang from comment #4) > > (In reply to Fabian Vogt from comment #3) > > > (In reply to Michael Chang from comment #1) [snip] > Having the return code would be very helpful. > > In the thread there's the theory that appending the entry to the event log > causes > it to fail, which sounds likely. According to the spec, it would then return > EFI_VOLUME_FULL, which is indeed not handled. This also explains why it only > fails > on snapshot boots (more commands to measure, which are all copied verbatim > into the > event log!) and why it gets worse on the second attempt. > > In the case of EFI_VOLUME_FULL, the correct behaviour is to log that and > continue, > as the measurement itself was successful. There's the option to retry with > EFI_TCG2_EXTEND_ONLY to skip logging, but in the case of a previous > EFI_VOLUME_FULL > error that will be returned again (it's sticky!), so there's no point... If the whole point here is to log the error EFI_VOLUME_FULL and continue execution as is, then it is not new to grub. I think there are other occasions where (non critical) errors are handled this way. The problem is do we have the hardware to verify it ? Should we make such error handling a common thing to all tpm's "unknown errors" ? > > > I hit something related on my machine (boo#1165773), where the FW claimed to > > > have a TPM event log without the TPM being enabled. > > > > Maybe such state can be reflect in EFI_TCG2_PROTOCOL.GetCapability ? It > > seems testing tpm presence is not enough. > > It should be... My point is that whenever tpm is disabled, no measurement should be performed hence users will not receive any errors related to tpm, otherwise it is confusing. An enhancement can thus be made if the test can cover both tpm presence and enablement and stop in advance. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1193486] criu package for openSUSE Leap 15.3 missing nftables support
by bugzilla_noreply＠suse.com 01 Apr '22

01 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193486 http://bugzilla.opensuse.org/show_bug.cgi?id=1193486#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Should be fixed for Leap 15.4. -- You are receiving this mail because: You are on the CC list for the bug.

1 0