openSUSE Bugs October 2022

bugs@lists.opensuse.org

1 participants
2089 discussions

[Bug 1197954] New: systemd-cryptsetup: Device root is still in use.
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1197954 Bug ID: 1197954 Summary: systemd-cryptsetup: Device root is still in use. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Starting with the Tumbleweed snapshot installed on March, 29th I got back an old error systemd-cryptsetup: Device root is still in use. systemd-cryptsetup: Failed to deactivate: Device or resource busy which shows up in the journal after switching root. I am not sure, but I believe that the reason for this is systemd[1]: plymouth-start.service: Unit process 394 (plymouthd) remains running after unit stopped. systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped because of a failed condition check (ConditionPathExists=!/run/plymouth/pid). which shows up in the journal just before the "in use" message. So plymouth didn't stop and the encrypted filesystem couldn't be unmounted. Before the last two snapshots the message looked like this: systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1200983] New: mouse & keyboard not available in X/plasma
by bugzilla_noreply＠suse.com 26 Mar '23

26 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1200983 Bug ID: 1200983 Summary: mouse & keyboard not available in X/plasma Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: opensuse(a)mike.franken.de QA Contact: gfx-bugs(a)suse.de Found By: --- Blocker: --- Starting with a few Tumbleweed snapshots ago I always have the problem, that mouse and keyboard are not working in my X/plasma desktop. I always have to unplug und plug them in again. After that they work as expected. There are no obvious error messages, that could help me to solve this problem. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1127591] New: zypper option "ssl_capath" not working for mirror URLs from metalink file
by bugzilla_noreply＠novell.com 25 Mar '23

25 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1127591 Bug ID: 1127591 Summary: zypper option "ssl_capath" not working for mirror URLs from metalink file Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)forge.provo.novell.com Reporter: cunix(a)bitmessage.ch QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- Using zypper (version: 1.14.12) for the update repository of openSUSE Leap 15.0 with the option baseurl=https://download.opensuse.org/update/leap/15.0/oss/?proxy=127.0.0.1… does not use the here configured trusted root certificates for mirror URLs, probably retrieved from a metalink file. The configured path is used for the initial connection to download.opensuse.org but following requests to mirrors seem to fallback to the system trusted certs from /etc/ssl/certs. If the mirrors' root CA is trusted in "ssl_capath=/path/to/directory/with/c_rehash/rootCAs" but not in /etc/ssl/certs, zypper,libzypp, multi-curl or something else aborts the TLS-Handshake with failure "Unknown CA (48)" and falls futher back to http (without transport layer encryption). Question for cc'ed security-team to answer: If using clear text is considered a security flaw where zypper is configured to use (https-)encryption, this might have security implications. Some Scenarios: Assume download.opensuse.org is signed by CA A and the mirror by CA B Assume further, ssl_capath=/path/to/directory/with/c_rehash/rootCAs is directory C and directory D is /etc/ssl/certs 1. If C includes A and B and in D at least B is not available, I would expect zypper to encrypt both connection, but the request to the mirror is not. 2. If A is not in C, no data (meta link file) is retrieved and therefore no mirror is connected - Good! No fallback of looking for A in D occurs. 3. If A is in C and B in D, both connections are encrypted. 4. If A is in C and B not in C and not in D, the mirror is contacted unencrypted - here I'm unsure if using plain text in this scenario is correct or if it should fail. So, in my opinion, 1. is the bug, 3. a workaround and 4. perhaps needs a zypper option to configure, if clear text fallback should be allowed. Another question is, if /etc/ssl/certs should actually be consulted when the option "ssl_capath" is used and pointing to a different directory. https://bugzilla.opensuse.org/show_bug.cgi?id=933839 might be related (similar setup). Problem and solution might be similar, too. By the way, is there a debugging option to dump the traffic from inside the encrypted connection? Especially being able to read the metalink file with the listed mirrors is of interest. -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1201144] New: Use KDE Discover to perform Distro Upgrades
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1201144 Bug ID: 1201144 Summary: Use KDE Discover to perform Distro Upgrades Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Upgrade Problems Assignee: screening-team-bugs(a)suse.de Reporter: johnmaverick74(a)mail.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Would be great to have Discover notifying the user when a new Distribution Upgrade becames available and being able to perform that upgrade (thru a GUI) similar to what happens in Kubuntu, Neon and soon Fedora KDE [0]. There was a project implementing this in Leap's GNOME software: [1] and [2] *[0] https://pagure.io/fedora-kde/SIG/issue/3 *[1] https://hackweek.opensuse.org/21/projects/implement-gnome-softwares-distrib… *[2] https://github.com/PackageKit/PackageKit/commit/930dd201b1da348f2a0ee7421c1… Other related Links: https://bugzilla.opensuse.org/show_bug.cgi?id=1197938 https://bugs.kde.org/show_bug.cgi?id=451849 https://hackweek.opensuse.org/projects/easy-opensuse-upgrade -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1178233] New: zypper up does not report any updates in WSL after longer pause
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1178233 Bug ID: 1178233 Summary: zypper up does not report any updates in WSL after longer pause Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: WSL Assignee: sle-ms(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-c(a)suse.de Found By: --- Blocker: --- I do have WSL images with Leap 15.2 and it seems that zypper doesn't register outdated repodata cache. Let's say that I'd start WSL image (bash session) once per two weeks, and if I simply run "zypper up" after these two weeks zypper reports no update, until I clean repodata I didn't call refresh simply up && clean --all && up and that worked fine. However I'd like to avoid situation when zypper simply reports no update with sporadically WSL use and user gets to believe it. My initial thought it's that this is caused by not having any services running inside the "container", however Ludwig things something might be wrong with the date/time inside the image. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1194723] New: automatically add dkms module after kernel update
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1194723 Bug ID: 1194723 Summary: automatically add dkms module after kernel update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: m.schenker(a)posteo.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi there, for certain scenarios I sometimes rely on kernel modules added via dkms. Initially installing them is as easy as the following. cd module-folder dkms install . From other distributions I am used that the module gets re-added/rebuild during a kernel update. However after a kernel update and reboot on Tumbleweed I just receive a message like the following one. modprobe: FATAL: Module vendor-reset not found in directory /lib/modules/5.16.0-1-default While the module still seems installed. user@computer:~/vendor-reset> sudo dkms install . Error! DKMS tree already contains: vendor-reset-0.1.1 You cannot add the same module/version combo more than once. It is not available to the updated kernel. There were two request for similar problems. 1. https://bugzilla.opensuse.org/show_bug.cgi?id=931175 Which resulted in a `don't care, won't fix 2. https://bugzilla.opensuse.org/show_bug.cgi?id=1184671 Which was ignored. I have not created kernel modules myself, so if there is something that needs to be done to the modules so they themselfs trigger an update I would be glad for a nudge in the right direction. However if there is something I would need to do in Tumbleweed I would be glad for help as well. I still see it as something that needs fixing since other Distributions, Arch, Ubuntu handle this on their own. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1203019] New: yast2: replace mkinitrd wrapper with native dracut
by bugzilla_noreply＠suse.com 24 Mar '23

24 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1203019 Bug ID: 1203019 Summary: yast2: replace mkinitrd wrapper with native dracut 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: antonio.feijoo(a)suse.com QA Contact: jsrain(a)suse.com Blocks: 1202351 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1202351 +++ Upstream support removed in March 2021 (https://github.com/dracutdevs/dracut/commit/43df4ee2) and deprecation announcement on factory mailing list in May 2021 (https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/…). ALP will not ship the mkinitrd wrapper, so it's better to get rid of it in Tumbleweed first. References: - yast2 /usr/share/YaST2/modules/Initrd.rb:72: # parametr for mkinitrd because of splash screen /usr/share/YaST2/modules/Initrd.rb:75: # Additional parameters for mkinitrd /usr/share/YaST2/modules/Initrd.rb:391: "/lib/mkinitrd/scripts/setup-splash.sh" /usr/share/YaST2/modules/Initrd.rb:400: "/sbin/mkinitrd %1 %2 >> %3 2>&1", /usr/share/YaST2/modules/Initrd.rb:405: File.join(Directory.logdir, "y2logmkinitrd").shellescape /usr/share/YaST2/modules/Initrd.rb:411: Ops.add(Directory.logdir, "/y2logmkinitrd") /usr/share/YaST2/modules/Initrd.rb:434: # Set the -s parameter of mkinitrd /usr/share/YaST2/modules/Initrd.rb:463: # Get additional parameters for mkinitrd /usr/share/YaST2/modules/Initrd.rb:464: # @return [String] additional mkinitrd parameters /usr/share/YaST2/modules/Initrd.rb:469: # Set additional parameters for mkinitrd /usr/share/YaST2/modules/Initrd.rb:470: # @param [String] params string additional mkinitrd parameters # rpm -qf /usr/share/YaST2/modules/Initrd.rb yast2-4.5.10-1.1.x86_64 - yast2-country /usr/share/YaST2/modules/Timezone.rb:85: # if mkinitrd should be called at the end /usr/share/YaST2/modules/Timezone.rb:86: @call_mkinitrd = false /usr/share/YaST2/modules/Timezone.rb:467: Builtins.y2milestone("calling mkinitrd...") /usr/share/YaST2/modules/Timezone.rb:470: "/sbin/mkinitrd >> /var/log/YaST2/y2logmkinitrd 2>> /var/log/YaST2/y2logmkinitrd" /usr/share/YaST2/modules/Timezone.rb:860: CallMkinitrd() if @call_mkinitrd && !Stage.initial /usr/share/YaST2/modules/Timezone.rb:1081: publish :variable => :call_mkinitrd, :type => "boolean" # rpm -qf /usr/share/YaST2/modules/Timezone.rb yast2-country-4.5.1-1.1.x86_64 - yast2-kdump /usr/share/YaST2/modules/Kdump.rb:419: update_command = (using_fadump? ? "/usr/sbin/mkdumprd -f" : "/sbin/mkinitrd") /usr/share/YaST2/modules/Kdump.rb:426: update_logfile = File.join(Directory.logdir, "y2logmkinitrd") # rpm -qf /usr/share/YaST2/modules/Kdump.rb yast2-kdump-4.5.3-1.1.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1089823] New: YaST can silently fail to run snapper during installation
by bugzilla_noreply＠novell.com 24 Mar '23

24 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1089823 Bug ID: 1089823 Summary: YaST can silently fail to run snapper during installation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: fvogt(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 767377 --> http://bugzilla.suse.com/attachment.cgi?id=767377&action=edit y2logs Installation with the live media and snapshots enabled fails: https://openqa.opensuse.org/tests/657353#step/await_install/21 This is because snapper is not installed in the installation system, so the snapper installation-helper is missing. So YaST needs to add a hard dependency there. The bigger issue is that YaST didn't care that the binary is not present though (found in y2log-3): [libstorage] ActiongraphImpl.cc:584 Commit Action "Mounting /dev/vda2 at /" [sid:59, first] [libstorage] SystemCmd.cc:67 constructor SystemCmd("/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'") [libstorage] SystemCmd.cc:186 SystemCmd Executing:"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:187 timestamp [295.985073], 2018-04-17 02:15:45 GMT, 2018-04-16 22:15:45 EDT [libstorage] SystemCmd.cc:660 Adding Line 1 "/bin/sh: /usr/lib/snapper/installation-helper: No such file or directory" [libstorage] SystemCmd.cc:626 pid:4219 added lines:1 stderr:true [libstorage] SystemCmd.cc:492 THROW: Command not found: "/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:416 stopwatch 0.010977s for "/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2' --description 'first root filesystem'" [libstorage] SystemCmd.cc:436 system() Returns:127 [libstorage] SystemCmd.cc:678 stderr:/bin/sh: /usr/lib/snapper/installation-helper: No such file or directory [libstorage] SystemCmd.cc:67 constructor SystemCmd("/sbin/udevadm settle --timeout=20") As can be seen, YaST notices the error but ignores it. Similar output for step 2. -- You are receiving this mail because: You are on the CC list for the bug.

2 19

[Bug 1191220] New: New Let's Encrypt certificate cannot be verify in Mono
by bugzilla_noreply＠suse.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1191220 Bug ID: 1191220 Summary: New Let's Encrypt certificate cannot be verify in Mono Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following fails: $ csharp -e 'new System.Net.WebClient ().DownloadString ("https://seznam.cz")' System.Net.WebException: Error: TrustFailure (Authentication failed, see inner exception.) ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED at /home/abuild/rpmbuild/BUILD/mono-6.12.0.107/external/boringssl/ssl/handshake_client.c:1132 at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00048] in <83dd749384734033afca92f4cfac782c>:0 at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status, System.Boolean renegotiate) [0x000da] in <83dd749384734033afca92f4cfac782c>:0 at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake(Mono.Net.Security.AsyncOperationStatus,bool) at Mono.Net.Security.AsyncHandshakeRequest.Run (Mono.Net.Security.AsyncOperationStatus status) [0x00006] in <83dd749384734033afca92f4cfac782c>:0 at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation (System.Threading.CancellationToken cancellationToken) [0x000fc] in <83dd749384734033afca92f4cfac782c>:0 --- End of inner exception stack trace --- at Mono.Net.Security.MobileAuthenticatedStream.ProcessAuthentication (System.Boolean runSynchronously, Mono.Net.Security.MonoSslAuthenticationOptions options, System.Threading.CancellationToken cancellationToken) [0x00262] in <83dd749384734033afca92f4cfac782c>:0 at Mono.Net.Security.MonoTlsStream.CreateStream (System.Net.WebConnectionTunnel tunnel, System.Threading.CancellationToken cancellationToken) [0x0016a] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebConnection.CreateStream (System.Net.WebOperation operation, System.Boolean reused, System.Threading.CancellationToken cancellationToken) [0x001ba] in <83dd749384734033afca92f4cfac782c>:0 --- End of inner exception stack trace --- at System.Net.WebConnection.CreateStream (System.Net.WebOperation operation, System.Boolean reused, System.Threading.CancellationToken cancellationToken) [0x0021a] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebConnection.InitConnection (System.Net.WebOperation operation, System.Threading.CancellationToken cancellationToken) [0x00141] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebOperation.Run () [0x0009a] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebCompletionSource`1[T].WaitForCompletion () [0x00094] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func`1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000f8] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.HttpWebRequest.GetResponse () [0x00016] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request) [0x00000] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadBits (System.Net.WebRequest request, System.IO.Stream writeStream) [0x000e6] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadDataInternal (System.Uri address, System.Net.WebRequest& request) [0x00061] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadString (System.Uri address) [0x00011] in <83dd749384734033afca92f4cfac782c>:0 at System.Net.WebClient.DownloadString (System.String address) [0x00008] in <83dd749384734033afca92f4cfac782c>:0 at <InteractiveExpressionClass>.Host (System.Object& $retval) [0x00006] in <bab8bbbe52954fd79168395f7636506e>:0 at Mono.CSharp.Evaluator.Evaluate (System.String input, System.Object& result, System.Boolean& result_set) [0x00038] in <dc18f8c1f3e14d9a83758fe12bb22a10>:0 at Mono.CSharpShell.Evaluate (System.String input) [0x00000] in <a01f5168c3824ddfb7cf74041d74890a>:0 It's discussed in the upstream issue: https://github.com/mono/mono/issues/12406 But I cannot fix it with: sudo cert-sync /etc/ssl/certs/ca-certificates.crt -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1133084] New: [META] GCC + LTO package failures
by bugzilla_noreply＠novell.com 23 Mar '23

23 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1133084 Bug ID: 1133084 Summary: [META] GCC + LTO package failures Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Meta issue that will track all packages that fail with enabled Link Time Optimization (LTO). For more detail description, please see: https://en.opensuse.org/openSUSE:LTO -- You are receiving this mail because: You are on the CC list for the bug.

2 183

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs October 2022