July 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1201114] mount fails after umount -R, then unplug/re-plug external drive
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201114 https://bugzilla.suse.com/show_bug.cgi?id=1201114#c1 Stanislav Brabec <sbrabec(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |genes1122(a)gmail.com, | |kernel-bugs(a)opensuse.org Flags| |needinfo?(genes1122(a)gmail.c | |om) --- Comment #1 from Stanislav Brabec <sbrabec(a)suse.com> --- Could you provide an output from mount command and contents of /proc/mounts after the first successful umount? And eventually output of dmesg and journalctl. And could you verify that nothing remains in the directory /mnt/chroot? (You can test "touch /mnt/chroot/nothing_is_mounted" before starting your experiments. You should see this file again when everything is unmounted.) It seems that something is still holding the old mount. It looks more like a kernel issue, as mount command is only a intermediary between user and kernel. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201296] New: seahorse-tool using 100% cpu
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201296 Bug ID: 1201296 Summary: seahorse-tool using 100% cpu Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: jmader2(a)gmu.edu QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Brand new OpenSUSE 15.4 install, noticed that seahorse-tool is running at 100% cpu using 17 hours of cpu time in 1 day. Tasks: 258 total, 2 running, 256 sleeping, 0 stopped, 0 zombie %Cpu(s): 24.4 us, 7.7 sy, 0.0 ni, 67.9 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 64248.52+total, 40212.84+free, 2416.648 used, 21619.03+buff/cache MiB Swap: 2048.812 total, 2048.812 free, 0.000 used. 61061.61+avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31385 tahan 20 0 671948 35012 28340 R 100.0 0.053 1077:21 seahorse-tool -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1198549] Update TLP to the latest version 1.5.0
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1198549 https://bugzilla.suse.com/show_bug.cgi?id=1198549#c12 Frank Kr�ger <fkrueger(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED Flags|needinfo?(fkrueger@mailbox. | |org) | --- Comment #12 from Frank Kr�ger <fkrueger(a)mailbox.org> --- Since this bug is about update to 1.5, it is solved, so I am closing it. Regarding battery power consumption w/a tlp 1.4/1.5 and power-profiles-daemon, I will do some tests. In case there is an issue, I will open a new bug report. Thx. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198549] Update TLP to the latest version 1.5.0
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1198549 https://bugzilla.suse.com/show_bug.cgi?id=1198549#c11 --- Comment #11 from Frank Kr�ger <fkrueger(a)mailbox.org> --- (In reply to Lars Vogdt from comment #7) > (In reply to Frank Kr�ger from comment #5) > > Afer update to tlp 1.5.0 together with the removal of power-profiles-daemon, > > my battery power consumption got worse. Is there any chance to change the > > conflicts option in the spec file? > > That sounds bad. > > Can I use you as tester? > > In case of 'yes': could you please forcefully install the > power-profiles-daemon together with tlp on your machine - and see if this > really solves your problem? Any idea how to install a confliction package using zypper? Thx. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198549] Update TLP to the latest version 1.5.0
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1198549 https://bugzilla.suse.com/show_bug.cgi?id=1198549#c10 --- Comment #10 from Frank Kr�ger <fkrueger(a)mailbox.org> --- (In reply to Eugene Popov from comment #8) > (In reply to Frank Kr�ger from comment #5) > > the removal of power-profiles-daemon > power-profiles-daemon should just be masked, not removed, so you just need > to unmask it (systemctl unmask power-profiles-daemon.service). It is removed during distribution upgrade by choosing 1: Problem: the to be installed tlp-1.5.0-1.1.noarch conflicts with 'power-profiles-daemon' provided by the installed power-profiles-daemon-0.11.1-1.2.x86_64 Solution 1: deinstallation of power-profiles-daemon-0.11.1-1.2.x86_64 Solution 2: deinstallation of tlp-1.4.0-1.5.noarch Solution 3: keep obsolete tlp-1.4.0-1.5.noarch -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201205] Kernel-default 5.18.9 hangs on boot
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201205 https://bugzilla.suse.com/show_bug.cgi?id=1201205#c24 --- Comment #24 from Frank Kr�ger <fkrueger(a)mailbox.org> --- (In reply to Thomas Zimmermann from comment #23) > Hi > > (In reply to Manfred Hollstein from comment #22) > > Just wanted to confirm that kernel-default-5.18.9-3.ga7c5f9c-default no > > longer has the problem, thanks for fixing! > > > > Here's my current setup: > > > > - TW20220705 > > - kernel-default-5.18.9-3.ga7c5f9c-default > > Thanks for testing. I close this issue as fixed. Let me just add that kernel-default-5.18.9-3.1.ga7c5f9c.x86_64 from kernel:stable with simpledrm enabled boots just fine. Thanks for your efforts. I appreciate it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201299] VUL-0: CVE-2022-31214: firejail: security update
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201299 Maintenance Robot <maint-coord+maintenance_robot(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1199895] PackageKit does not honor zypper package locks
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1199895 https://bugzilla.suse.com/show_bug.cgi?id=1199895#c15 Michael Andres <ma(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(zypp-maintainers@ | |suse.de) | --- Comment #15 from Michael Andres <ma(a)suse.com> --- I can't tell that I fully understand what PK is doing, but I've got a suspect. Some of your *_tread functions use your PoolStatusSaver to capture the status of all PoolItems and to restore it when the function is left. This is needed, because the code makes heavy use of calling PoolItem::statusReset(). Doing this you clear all status information including the bit that tells that the package is locked. I guess your funtions using a pattern like ResPool pool = zypp_build_pool (zypp, true); PoolStatusSaver saver; ... are safe because they restore all status changes the may have applied. Others like backend_what_provides_thread may persistently clear the status of items: > if(g_ascii_strcasecmp("drivers_for_attached_hardware", values[0]) == 0) { > ... > for (ResPool::byKind_iterator it = pool.byKindBegin (ResKind::package).... > ... > it->statusReset (); > } This may be where you lose the locks. But also be careful with your PoolStatusSaver implementation. The ResPool::instance().proxy().saveState/restoreState calls it uses are not stacked. So you must not nest your PoolStatusSaver instances. restoreState restores the last saveState, no matter from where you called it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201299] VUL-0: CVE-2022-31214: firejail: security update
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201299 https://bugzilla.suse.com/show_bug.cgi?id=1201299#c1 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|CVE-2022-31214: firejail |VUL-0: CVE-2022-31214: |security update |firejail: security update --- Comment #1 from Marcus Meissner <meissner(a)suse.com> --- dup of bug 1199148 we did this already via backports. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201291] New: tpm2.0-tools tpm2_makecredential broken when -T none is set
by bugzilla_noreply＠suse.com 07 Jul '22

07 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201291 Bug ID: 1201291 Summary: tpm2.0-tools tpm2_makecredential broken when -T none is set Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: aplanas(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- tpm2_makecredential is a tools used in a process that make the AK validated against an EK, so a 3rd party will be sure that the AK and the EK are related. This process can be done more or less like this (this is for a local example, for a remote one we need to copy the AK public and private keys, the EK public key and the AK name into the 3rd party): # Create a secret echo "12345678" > secret.data # In the EK / AK owner create the EK context and the AK pair # If the AK is already present it can be loaded tpm2_createek -c ek_handle -u ek.pub tpm2_createak -C ek_handle -c ak.ctx -u ak.pub -n ak.name > ak.out # Get the AK name. It is also present in ak.out file_size=`stat --printf="%s" ak.name` loaded_key_name=`cat ak.name | xxd -p -c $file_size` # Encrypt the secret using the EK pub and the AK name. This should be done # in the 3rd party, so the prove is that the EK /AK owner is the only one # that can decrypt it. # Also, -T none is used because it is not required the TPM (bug here) tpm2_makecredential -T none -e ek.pub -s secret.data -n $loaded_key_name -o mkcred.out # Only the owner of the EK / AK can decrypt it tpm2_startauthsession --policy-session -S session.ctx tpm2_policysecret -S session.ctx -c e tpm2_activatecredential -c ak.ctx -C ek_handle -i mkcred.out -o actcred.out -P"session:session.ctx" tpm2_flushcontext session.ctx # Should be the same cat secret.data actcred.out The problem is that when using "-T none", some garbage get injected in the mkcred.out that make it impossible to decrypt, but if some TCTI is specified it will work. Seems that this bug is only present in 5.2 when LTO is activated. HEAD does not contain the bug even when LTO is active during compilation, and seems that it is fixed as a side effect of this refactoring change in upstream: https://github.com/tpm2-software/tpm2-tools/pull/2880 Sadly backporting it is not enough, so I think LTO should be disabled for the 5.2 version (and re-enabled later for the next release). -- You are receiving this mail because: You are on the CC list for the bug.

1 1