November 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1209294] New Thinkpad T14s GPU reset/crash with openSUSE Tumbleweed
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1209294 https://bugzilla.suse.com/show_bug.cgi?id=1209294#c9 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Flags|needinfo?(martin.liska@suse | |.com) | --- Comment #9 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Daniel Wagner from comment #8) > My laptop seems to sport the same gpu: > > 33:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Rembrandt [Radeon 680M] (rev d1) Yes, that's the HW. I have the same and I assume many of us, given it's the company machine. Unlike you, I cannot repro easily (how do you?), so once a fix is known, I hope you don't mind if I will ask you for testing? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207376] vmware-view crashes with general protection fault in libgobject-2.0.so.0.7000.5
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1207376 https://bugzilla.suse.com/show_bug.cgi?id=1207376#c5 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Virtualization:Other Flags|needinfo?(chcao(a)suse.com) | Assignee|cloud-bugs(a)suse.de |virt-bugs(a)suse.de --- Comment #5 from Chenzi Cao <chcao(a)suse.com> --- Reassign it to virtualization team to take a look at it, thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1200594] Certain applications do not honor keyboard layout settings
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1200594 https://bugzilla.suse.com/show_bug.cgi?id=1200594#c8 --- Comment #8 from Bryce Halling <bryce.halling(a)suse.com> --- This might be an issue specific to all the keyboards I tested previously. All of those keyboards present multiple interfaces that all used the same modalias. I tracked down a keyboard that only presented a single interface and that one remaps just fine. If the hardware weren't broken and presenting multiple devices with the same identifier, this would not be a problem. Based on this info, I doubt that the EVIOCSKEYCODE messages reported here have anything to do with the problem in the original comment. This isn't likely something that just changed in udev recently as evidenced by the symptoms popping up in a recent Tubleweed snapshot. Thanks for the engagement Michal. I'll go ahead and back out of this bug as it seems to be unrelated to what I observed on my hardware. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1216845] New: locale language environment, fonts fallback doesn't work.
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1216845 Bug ID: 1216845 Summary: locale language environment, fonts fallback doesn't work. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Usability Assignee: screening-team-bugs(a)suse.de Reporter: razorbacky(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 870610 --> https://bugzilla.suse.com/attachment.cgi?id=870610&action=edit en_US.UTF-8 # reference what is this component. I reproduced the phenomenon in a virtual machine to maintain my normal environment. Font fallback does not work in two identical environments with different language locales. one, LANG=en_US.UTF-8 the other one, LANG=ko_KR.UTF-8 (please attached images) fallback to awesome fonts. LANG=en_US.UTF-8 environment font fallback is work. but, LANG=ko_KR.UTF-8 environment font fallback doeson't work. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1200594] Certain applications do not honor keyboard layout settings
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1200594 https://bugzilla.suse.com/show_bug.cgi?id=1200594#c7 --- Comment #7 from Bryce Halling <bryce.halling(a)suse.com> --- (In reply to Michal Suchanek from comment #6) > hm, or maybe my setup is special in that the keys are interpreted by the > window manager and not the application. > > And in that I am running X11, and not Wayland. X11 here as well. I can remap, but only using higher level tools like xkb or xmodmap. At the udev level, tested using multiple USB keyboards from several vendors, I get the error message and no remapping. Worth noting is that I also just saw the exact same behavior on an Arch install running on completely separate hardware, so I may be better served just taking the report upstream as it seems it may originate there. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201074] Greybird and Greybird-geeko themes need newer sassc version
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1201074 https://bugzilla.suse.com/show_bug.cgi?id=1201074#c9 Yifan Jiang <yfjiang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(yfjiang(a)suse.com) | --- Comment #9 from Yifan Jiang <yfjiang(a)suse.com> --- (In reply to Olivier Tilloy from comment #8) > I rebuilt sassc against libsass 3.6.5 in this maintenance incident: > https://build.suse.de/project/show/SUSE:Maintenance:31377. > > Yifan Jiang, could you please test the packages there and confirm that sassc > is working as expected and that this fixes the problem you were seeing? > Thanks! Hi Olivier, the new build works fine for me. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1216704] New: mozilla:Factory/MozillaFirefox: Bug
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1216704 Bug ID: 1216704 Summary: mozilla:Factory/MozillaFirefox: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: wolfgang(a)rosenauer.org Reporter: pallaswept(a)proton.me QA Contact: screening-team-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- There is a bug with this package, specific to OpenSUSE Wayland sessions. Please see https://bugzilla.opensuse.org/show_bug.cgi?id=1215137, Which refers to https://bugzilla.mozilla.org/show_bug.cgi?id=1851505 and https://bugzilla.mozilla.org/show_bug.cgi?id=1851503 Thanks for any help with this. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1199618] [Build 20220516] openQA test fails in fanotify16 (LTP)
by bugzilla_noreply＠suse.com 03 Nov '23

03 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1199618 WEI GAO <wegao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1216841 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1215355] AUDIT-0: himmelblau: review of PAM module pam_himmelblau.so
by bugzilla_noreply＠suse.com 02 Nov '23

02 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1215355 https://bugzilla.suse.com/show_bug.cgi?id=1215355#c13 William Brown <william.brown(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #13 from William Brown <william.brown(a)suse.com> --- Sorry didn't realise I was the blocker here! > > > > The cleartext password is passed around a lot in the Rust program as well as > > in the Python parts so clearing it reliably from memory is out of the > > question - which is otherwise a hardening measure that some PAM module > > attempt > > to achieve. > > > > It looks like the msal package passes the cleartext password on to the third > > party servers e.g. in msal/oauth2cli/oauth2.py:182 `_obtainToken()`. This > > means it should be avoided passing on passwords for accounts that aren't > > supposed to be authenticated this way, most notably root, of course. Do you > > have logic in place that prevents that? > > `process_etc_passwd_group` in the daemon collects local users/groups and > loads them into the cache nxset, which is meant to reject auth for local > user/group names. William, I'm looking over the nxset check though, and it > looks like it doesn't happen until after attempting to auth (in the resolver > code)? I'm pretty sure I've seen the opposite behavior though, so can you > comment on this William? To trace this out, let's assume we're doing a pam flow. This starts in pam_account_authenticate which then immediately tries to get the users token (information token here, not auth token). This is done with pam_account_authenticate_init which immediately calls get_cached_usertoken. This calls dbtxn.get_account(). If the user is in the DB, then we return the info. If they aren't found, we check the nxcache. So lets be clear here, if the user is part of the nxset (aka a local account or id) they can not be part of the db cache, and they won't be in the nxcache. So this will always return None. At this point we also don't know if the name given to us by the requestor (such as "admin") will actually resolve differently into the user token. Kanidm allows this where you can login with "william" but it will resolve and render to "william(a)idm.suse.com". So we have to proceed with the auth here because we don't know the final state of the users id yet. The auth session then starts and we step with the pam module collecting credentials and components with pam_account_authenticate_step until we get to AuthResult::Success back from the provider in that function. At that point we now have the users fully resolved identity in the token returned to us by the provider. This is where we check the nxset to see if there is an identity collision, of the id of the user as it would be *resolved* on the system. If there is a collision, we return a pam denied. So to summarise: * local system users can't be in the nxcache or the dbcache * we can't check the nxset until the auth completes because we don't know the final name/gid/uid of the account until auth completes * if the user has a name/gid/uid conflict, we are checking the *remote* provider credentials, not the local /etc/shadow credentials, so this is not somehow exposing attacks again local users. * the nxset contains all local account names and uid/gids to ensure that there are no ways for a remote user to "claim" being a local system account. * The nxset is watched with inotify to ensure any live changes to the system are immediately reflected in the resolver Hope that helps :) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1216463] Default UEFI firmware choice set up by gnome-boxes Windows 10/11 assistant can't boot into Windows 10 install disk
by bugzilla_noreply＠suse.com 02 Nov '23

02 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1216463 https://bugzilla.suse.com/show_bug.cgi?id=1216463#c11 --- Comment #11 from ell1e <el(a)horse64.org> --- I tried enabling libvirtd now, it indeed wasn't running. I also was then prompted for the root password by virt-manager. However, starting the VM after that made no difference, as far as I can tell everything behaves the same way, including the CD ROM not booting. For what it's worth the VM is currently set to TPM 1.2 since I couldn't get TPM 2.0 to work, maybe that would be solved by libvirtd. But from my understanding of Windows 10, it shouldn't matter for being able to boot a Windows 10 ISO. (While I eventually plan to upgrade to Windows 11 which is more picky there I imagine, I would first have to manage to make my Windows 10 install boot again.) -- You are receiving this mail because: You are on the CC list for the bug.

1 0