April 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1210262] New: libgamemode0-32bit was removed
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210262 Bug ID: 1210262 Summary: libgamemode0-32bit was removed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: abc.mikey(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- As per this discussion on the mailing list: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… A number of 32 bit packages, were removed, and a bug report should be made for those that are still required. libgamemode0-32bit is still required as many games on steam are still 32bit and require libgamemode0-32bit to be able to use gamemoderun, i.e. run the game in performance mode. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1210261] New: mangohud-32bit was removed
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210261 Bug ID: 1210261 Summary: mangohud-32bit was removed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: abc.mikey(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0 Build Identifier: As per this discussion on the mailing list: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… A number of 32 bit packages, were removed, and a bug report should be made for those that are still required. mangohud-32bit is still required as many games on steam are still 32bit and require mangohud-32bit to be able to use mangohud, i.e. show the performance graphs in game. Reproducible: Always Steps to Reproduce: 1. try launching 32bit game in steam with: mangohud %COMMAND% Actual Results: elf class warnings for mangohud Expected Results: shows performance graphs in game -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1209457] NFSv4 broken after kernel update (5.14.21-150400.24.46-default to 5.14.21-150400.24.49)
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1209457 https://bugzilla.suse.com/show_bug.cgi?id=1209457#c42 --- Comment #42 from St�phane DESNEUX <sdx(a)iot.bzh> --- Created attachment 866211 --> https://bugzilla.suse.com/attachment.cgi?id=866211&action=edit Test 2 wireshark captures -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209457] NFSv4 broken after kernel update (5.14.21-150400.24.46-default to 5.14.21-150400.24.49)
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1209457 https://bugzilla.suse.com/show_bug.cgi?id=1209457#c41 --- Comment #41 from St�phane DESNEUX <sdx(a)iot.bzh> --- Created attachment 866210 --> https://bugzilla.suse.com/attachment.cgi?id=866210&action=edit Test 2 description -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1210264] New: New installation option: partial disk encryption with Trusted Platform
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210264 Bug ID: 1210264 Summary: New installation option: partial disk encryption with Trusted Platform Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: slawek(a)lach.art.pl QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Currently, installers offers full disk encryption or allows user to configure it by themselves. My idea is to add unencrypted storage to save up space. In unencrypted storage will be stored only non-private data, like programs executable, programs data, etc. But.... Each of file in unencrypted data should been signed or system deny to load it. Even program data could have fingerprint and open* functions family could been altered to return -1 and set errno, when file do not have correct fingerprint. Why? To reduce disk usage. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209974] New: firefox cannot play video
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209974 Bug ID: 1209974 Summary: firefox cannot play video Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: wzyhktk(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Firefox cannot play video on leap 15.5, although all codecs have been installed. while the flatpak version firefox works fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1210259] New: the installed pam_kwallet-32bit-5.27.3-1.2.x86_64 requires 'pam_kwallet = 5.27.3', but this requirement cannot be provided
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210259 Bug ID: 1210259 Summary: the installed pam_kwallet-32bit-5.27.3-1.2.x86_64 requires 'pam_kwallet = 5.27.3', but this requirement cannot be provided Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Upgrade Problems Assignee: screening-team-bugs(a)suse.de Reporter: skovalyov(a)ukr.net QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Doing zypper dup I got this message: the installed pam_kwallet-32bit-5.27.3-1.2.x86_64 requires 'pam_kwallet = 5.27.3', but this requirement cannot be provided deleted providers: pam_kwallet-5.27.3-1.2.x86_64 Solution 1: Following actions will be done: deinstallation of samba-client-libs-32bit-4.18.0+git.294.508b693e5c-1.1.x86_64 deinstallation of pam-32bit-1.5.2-14.1.x86_64 deinstallation of pam_pwquality-32bit-1.4.5-1.2.x86_64 deinstallation of gnome-keyring-pam-32bit-42.1-2.2.x86_64 Solution 2: deinstallation of pam_kwallet-5.27.3-1.2.x86_64 Solution 3: keep obsolete pam_kwallet-5.27.3-1.2.x86_64 Solution 4: break pam_kwallet-32bit-5.27.3-1.2.x86_64 by ignoring some of its dependencies None of the above solution is good. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1210258] New: Configuring network for No Link and IP Setup still enables IPv6
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210258 Bug ID: 1210258 Summary: Configuring network for No Link and IP Setup still enables IPv6 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: aaronw(a)doofus.org QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- I have a setup where I have two network cards and two bridges. br0 is connected to the first network card and br1 is connected to the second network card. I am using bridges for VMs. In my case, for br1 I do not want any IP addresses since this port is connected directly to the internet and should be accessed only by a VM. The problem I am seeing is that even though YaST has br1 configured for No Link and IP Setup (Bond Ports), it is still obtaining an IPv6 address. If I configure a port for no IPv6 then it should not attach any protocols to that port, IPv4 or IPv6. How to recreate: 1. Configure a bridge with one network card and set it to No Link and IP Setup (Bond Ports) 2. Plug the cable into an IPv6 enabled network 3. Type ip -6 a 4. Notice that routeable IPv6 addresses get assigned. 7: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group ip -6 a ... 7: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 10:7b:44:91:3e:c9 brd ff:ff:ff:ff:ff:ff inet6 2603:3024:XXXX:XXXX:XXXX:XXXX:XXXX:37b8/64 scope global temporary dynamic valid_lft 299sec preferred_lft 299sec inet6 2603:3024:XXXX:XXXX:XXXX:XXXX:XXXX:3ec9/64 scope global dynamic mngtmpaddr valid_lft 299sec preferred_lft 299sec inet6 fe80::XXXX:XXXX:XXXX:3ec9/64 scope link valid_lft forever preferred_lft forever /etc/sysconfig/network/ifcfg-br1 contains the following: IPADDR='0.0.0.0' MTU='0' BOOTPROTO='none' STARTMODE='auto' ZONE='external' BRIDGE='yes' BRIDGE_PORTS='eth1' BRIDGE_STP='off' BRIDGE_FORWARDDELAY='15' I know IPv6 can be disabled via sysctl, but it should also be possible in YaST2. This can be a security issue, as it is for me. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209457] NFSv4 broken after kernel update (5.14.21-150400.24.46-default to 5.14.21-150400.24.49)
by bugzilla_noreply＠suse.com 08 Apr '23

08 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1209457 https://bugzilla.suse.com/show_bug.cgi?id=1209457#c40 --- Comment #40 from Neil Brown <nfbrown(a)suse.com> --- Thanks for the testing and packet capture. Unfortunately I cannot see anything interesting in them. As you say: the showmount and the mount;ls do actually work in both cases. You say that with 55.3 commands are less "reactive". I assume that means the response is slower. I cannot see any evidence of that in the trace - replies come within milliseconds. There is a known problem with QNAP which is triggered by a recent change in Linux NFS. We do have the fix to avoid triggering this bug but I don't think that update has been released yet. Once you get a kernel that was released after 22/Mar/2023 QNAP should be fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209457] NFSv4 broken after kernel update (5.14.21-150400.24.46-default to 5.14.21-150400.24.49)
by bugzilla_noreply＠suse.com 07 Apr '23

07 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1209457 https://bugzilla.suse.com/show_bug.cgi?id=1209457#c39 --- Comment #39 from St�phane DESNEUX <sdx(a)iot.bzh> --- Hi, As Neil asked, I captured the traffic for showmount/mount/ls/umount with different configs. I made a first test (namely "Test 1" in attachments) between two Leap 15.4 hosts and captured the traffic with wireshark on server side (see attached tarball). I confirm that I'm able to showmount/mount with kernel .55.3 between the two machines (the client is on .55.3, the server is on .46.1). But, with .55.3 on the client side, the commands are less "reactive". Studying the captures may help, as they seem different. This confirms the comment #36 by Peter Varga, but... I tested the same commands with my old QNAP NAS which has not been updated recently and used to work like a charm for the past 10 years... and it still fails. First result with the QNAP NAS: - showmount works - mount fails (blocking forever, no error in kernel messages) I'll redo the same tests with my QNAP NAS instead of the Leap 15.4 Server and post the results and captures here. NB: I noticed a strange behavior: usually, when a NFS resource is not available, all accesses are blocked. But after a "short" timeout (30s maybe), the blocking calls are unblocked and everything "fails correctly". In the current case, the mount operation and all accesses to the mounted folder are blocked forever (or with a very high timeout, that I never reached = more than 10mn at least). This is really an unexpected behavior and it has really nasty side effects :\ like a gnome session not really starting: the gnome-shell process can be blocked for any reason due to an access to the mounted folder => black screen with a single mouse pointer on it... My wife who is not a Linux expert had the issue just after an automatic update on her Leap 15.4 laptop... and asked me for tech support. I hope that not all laptop users with a QNAP NAS will have the same experience and that we're on a corner case! -- You are receiving this mail because: You are on the CC list for the bug.

1 0