February 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1163179] nscd can't monitor /etc/services after the recent netcfg update
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1163179 http://bugzilla.suse.com/show_bug.cgi?id=1163179#c3 --- Comment #3 from Martin Koller <kollix(a)aon.at> --- I am aware of this and did it before searching bugzilla but still see that nfs-server can not start. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1163179] nscd can't monitor /etc/services after the recent netcfg update
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1163179 http://bugzilla.suse.com/show_bug.cgi?id=1163179#c2 --- Comment #2 from Thorsten Kukuk <kukuk(a)suse.com> --- (In reply to Martin Koller from comment #1) > Worse than the message is the fact that nfs-server won't start any longer! > (as a workaround I made a symlink /etc/services -> /usr/etc/services) Merge your *.rpmnew and *.rpmsave files with your own changes to configuration files. If you don't do that, your system can become inscure or services stop working. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1163232] New: Gnome-boxes forcedly rewrite costom cpu cores setting
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1163232 Bug ID: 1163232 Summary: Gnome-boxes forcedly rewrite costom cpu cores setting Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: hillwoodroc(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I try to set cpu cores as the number which I want, but after I use gnome-boxes to boot the vm machine, the cpu cores setting will be forcedly rewrited as the physical number by gnome-boxes. The virt-manager have not this issue. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1163120] No mitigations for CPU vulnerabilities
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1163120 http://bugzilla.suse.com/show_bug.cgi?id=1163120#c14 --- Comment #14 from Suse User <suseino(a)riseup.net> --- Thank you! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1160244] [META] -fno-common package failures
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1160244 Bug 1160244 depends on bug 1160413, which changed state. Bug 1160413 Summary: postfix fails with -fno-common http://bugzilla.suse.com/show_bug.cgi?id=1160413 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1160413] postfix fails with -fno-common
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1160413 http://bugzilla.suse.com/show_bug.cgi?id=1160413#c6 Martin Liška <martin.liska(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška <martin.liska(a)suse.com> --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1137373] Systemd mount and unmount partition during boot
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1137373 http://bugzilla.opensuse.org/show_bug.cgi?id=1137373#c24 --- Comment #24 from Franck Bui <fbui(a)suse.com> --- This is an upstream issue which is not specific to openSUSE but affects all distros and as such is dealt at https://github.com/systemd/systemd/issues/12953. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1162471] [Build 20200131] Kernel 5.5/btrfs 'eats' disk space
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1162471 http://bugzilla.suse.com/show_bug.cgi?id=1162471#c10 --- Comment #10 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #9) > It must be a different bug, or the patch does not work. On that note, I believe this bug was not introduced in 5.4, but in 5.5. Or 5.5 somehow catalysed it. We would have a ton of reports with 5.4 which did not happen. After update to 5.5, we have many. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1162471] [Build 20200131] Kernel 5.5/btrfs 'eats' disk space
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1162471 http://bugzilla.suse.com/show_bug.cgi?id=1162471#c9 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? | --- Comment #9 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #8) > So let's see if that helps: > https://build.opensuse.org/request/show/769861 It seems not: https://lists.opensuse.org/opensuse-factory/2020-02/msg00232.html It must be a different bug, or the patch does not work. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1162365] New: if the lock does not use lock elision pthread_mutex_destroy will fail
by bugzilla_noreply＠novell.com 10 Feb '20

10 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1162365 Bug ID: 1162365 Summary: if the lock does not use lock elision pthread_mutex_destroy will fail Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: x86-64 OS: All Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jan.m.michalski(a)intel.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Source code: https://github.com/janekmi/pmdk/blob/test-pthread-3/src/test/obj_pmalloc_mt… Makefile: https://github.com/janekmi/pmdk/blob/test-pthread-3/src/test/obj_pmalloc_mt… Distro: openSUSE Leap 15.1 Kernel: 4.12.14-lp151.28.36-default Glibc: glibc-devel-2.26-lp151.18.7.x86_64 CPU: Intel(R) Xeon(R) Gold 6142M CPU @ 2.60GHz Scenario: Two worker threads at the same time are using a common set of primitives: struct action { pthread_mutex_t lock; pthread_cond_t cond; unsigned val; }; One of the threads is waiting on pthread_cond_t while another is setting val to 1. Everything happens in the action_cancel_worker function: https://github.com/janekmi/pmdk/blob/test-pthread-3/src/test/obj_pmalloc_mt… After exiting from the worker thread all mutexes should be unlocked so it should be possible to destroy them. But they are not. pthread_mutex_destroy fails with EBUSY. Repro: $ ./locking_issue_repro 32 1000 pthread_mutex_destroy: Device or resource busy Note: After each pthread_mutex_lock and pthread_mutex_unlock API call internal state of the mutex is dumped to /dev/shm/obj_pmalloc_mt_dump file. The key is: TID -> actions[worker-id][op-id] = {data read from the pthread_mutex_t} (stage of the worker) Issue: (appears sporadically, but at least 1/5): $ cat /dev/shm/obj_pmalloc_mt_dump | tail 2793 -> actions[7][996] = {nusers: 0, owner: 0, kind: 256} (unlock t1) 2793 -> actions[7][997] = {nusers: 0, owner: 0, kind: 256} (lock t1) 2793 -> actions[7][997] = {nusers: 0, owner: 0, kind: 256} (unlock t1) 2793 -> actions[7][998] = {nusers: 0, owner: 0, kind: 256} (lock t1) 2793 -> actions[7][998] = {nusers: 0, owner: 0, kind: 256} (unlock t1) 2793 -> actions[7][999] = {nusers: 0, owner: 0, kind: 256} (lock t1) 2793 -> actions[7][999] = {nusers: 0, owner: 0, kind: 256} (unlock t1) 2777 -> actions[7][710] = {nusers: 1, owner: 2793, kind: 256} (dump) 2777 -> actions[7][794] = {nusers: 1, owner: 2793, kind: 256} (dump) Clues: All of the locks are of the kind: PTHREAD_MUTEX_ELISION_NP so nearly all of them looks as follows: 2792 -> actions[7][711] = {nusers: 0, owner: 0, kind: 256} (lock t0) 2792 -> actions[7][711] = {nusers: 0, owner: 0, kind: 256} (unlock t0) 2793 -> actions[7][711] = {nusers: 0, owner: 0, kind: 256} (lock t1) 2793 -> actions[7][711] = {nusers: 0, owner: 0, kind: 256} (unlock t1) So it looks like all of them are use lock elision. But if any of them does not use lock elision it behaves strangely: - it seems locked all the time: $ cat /dev/shm/obj_pmalloc_mt_dump | grep \\[7\\] | grep 710 2793 -> actions[7][710] = {nusers: 1, owner: 2793, kind: 256} (lock t1) // no matter if it is after lock 2792 -> actions[7][710] = {nusers: 1, owner: 2793, kind: 256} (lock t0) 2792 -> actions[7][710] = {nusers: 1, owner: 2793, kind: 256} (unlock t0) // or after unlock 2793 -> actions[7][710] = {nusers: 1, owner: 2793, kind: 256} (unlock t1) 2777 -> actions[7][710] = {nusers: 1, owner: 2793, kind: 256} (dump) - but at the same time, they work fine! - excluding the fact they are impossible to destroy them - the rule is: if the lock does not use lock elision it will fail during pthread_mutex_destroy. -- You are receiving this mail because: You are on the CC list for the bug.

1 4