July 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1096401] snapper: segfault found in openQA tests
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096401 http://bugzilla.suse.com/show_bug.cgi?id=1096401#c11 --- Comment #11 from Oliver Kurz <okurz(a)suse.com> --- (In reply to Stefan Schubert from comment #9) > […] > > The three snaperd coredumps are available in the openQA provided tarball > > https://openqa.opensuse.org/tests/688332/file/gimp-problem_detection_logs. > > tar.xz > Hm, this file does not exist anymore. Could you please point us to it again ? openQA cleans up logs and then older openQA jobs after some time. I wonder why the one-month job already deleted its jobs but as a hint: Jobs are kept around longer than logs so the job https://openqa.opensuse.org/tests/688332 itself is still there. From there we can find the link to the always "latest": https://openqa.opensuse.org/tests/latest?flavor=NET&machine=64bit&arch=x86_… this points me to the two latest failures https://openqa.opensuse.org/tests/700735 failing in gnucash and https://openqa.opensuse.org/tests/700420 failing in chromium. I think in both cases we would be able to find these logs. > Additional it would be nice if you point us to the point where it happens in > this test. (The test is quite huge :-)) > > > > (directory coredumps) In the aforementioned test failures I can find references to the core dump, e.g. in https://openqa.opensuse.org/tests/700735/file/gnucash-journal.log I see ``` Jul 03 04:10:40 susetest org.opensuse.Snapper[729]: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >' Jul 03 04:10:40 susetest org.opensuse.Snapper[729]: what(): boost: mutex lock failed in pthread_mutex_lock: Invalid argument Jul 03 04:10:40 susetest systemd[1]: Created slice system-systemd\x2dcoredump.slice. Jul 03 04:10:40 susetest systemd[1]: Started Process Core Dump (PID 7421/UID 0). Jul 03 04:10:40 susetest systemd-coredump[7422]: Process 5743 (snapperd) of user 0 dumped core. ``` so to identify further at which point in time within the test this happens we can take a look at the timestamp. https://openqa.opensuse.org/tests/700735#step/keymap_or_locale/10 is at 03:56 so before, https://openqa.opensuse.org/tests/700735#step/consoletest_finish/17 is at 04:17 after that. Taking a look into the journal again I can find the lines ``` Jul 03 04:09:56 susetest systemd[1]: Started The Salt Minion. Jul 03 04:10:19 susetest salt-minion[7008]: [ERROR ] The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate Jul 03 04:10:29 susetest salt-minion[7008]: [ERROR ] The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate ``` that is just 11 seconds before the above error message at 04:10:40 and the next message after the snapper error messages is ``` Jul 03 04:11:03 susetest systemd[1]: Stopping The Salt Master Server... ``` that is 23 seconds later. With this https://openqa.opensuse.org/tests/700735#step/salt/14 is the step just in before within the test module "salt", https://openqa.opensuse.org/tests/700735#step/salt/24 is the step afterwards. I have a suspicion that the snapper core dump is related to installing packages which should also trigger snapper to create snapshots, right? E.g. from https://openqa.opensuse.org/tests/700735/file/gnucash-y2logs_clone.tar.bz2 we can also find the zypper.log stating: ``` 2018-07-03 04:09:39 <2> susetest(6262) [PLUGIN] PluginScript.cc(~PluginDumpStderr):75 ! INFO:root:creating post snapshot 2018-07-03 04:09:39 <2> susetest(6262) [PLUGIN] PluginScript.cc(~PluginDumpStderr):75 ! DEBUG:root:created post snapshot 8 2018-07-03 04:09:39 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(receive):426 PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py <-PluginFrame[ACK](0){0} 2018-07-03 04:09:39 <1> susetest(6262) [zypp::plugin++] PluginExecutor.cc(send):94 --------------- send PluginFrame[COMMITEND](0){4556} 2018-07-03 04:09:39 <1> susetest(6262) [zypp] PathInfo.cc(dirForEach):553 readdir /etc/products.d 2018-07-03 04:09:39 <1> susetest(6262) [zypp] TargetImpl.cc(buildCache):850 Read cookie: /var/cache/zypp/solv/@System/cookie{- 0644 0/0 size 52} 2018-07-03 04:09:39 <1> susetest(6262) [zypp] TargetImpl.cc(buildCache):857 Read cookie: /var/cache/zypp/solv/@System/cookie says: outdated 2018-07-03 04:09:39 <1> susetest(6262) [zypp::exec++] ExternalProgram.cc(start_program):252 Executing 'rpmdb2solv' '-r' '/' '-X' '-A' '-p' '/etc/products.d' '/var/cache/zypp/solv/@System/solv' '-o' '/var/cache/zypp/solv/@System/solvP20RfW' 2018-07-03 04:09:39 <1> susetest(6262) [zypp::exec++] ExternalProgram.cc(start_program):415 pid 6943 launched 2018-07-03 04:09:39 <1> susetest(6262) [zypp::exec++] ExternalProgram.cc(checkStatus):516 Pid 6943 successfully completed 2018-07-03 04:09:39 <1> susetest(6262) [zypp] PathInfo.cc(rename):701 rename /var/cache/zypp/solv/@System/solvP20RfW -> /var/cache/zypp/solv/@System/solv 2018-07-03 04:09:39 <1> susetest(6262) [zypp] PathInfo.cc(chmod):1051 chmod /var/cache/zypp/solv/@System/solv 00644 2018-07-03 04:09:39 <1> susetest(6262) [zypp::plugin++] PluginExecutor.cc(load):53 +++++++++++++++ load /usr/lib/zypp/plugins/system{d 0755 0/0} 2018-07-03 04:09:39 <1> susetest(6262) [zypp] PathInfo.cc(dirForEach):553 readdir /usr/lib/zypp/plugins/system 2018-07-03 04:09:39 <1> susetest(6262) [zypp::plugin++] PluginExecutor.cc(load):80 --------------- load /usr/lib/zypp/plugins/system{d 0755 0/0} 2018-07-03 04:09:39 <1> susetest(6262) [zypp] TargetImpl.cc(commit):1338 TargetImpl::commit(<pool>, CommitPolicy( DownloadInHeaps )) returns: CommitResult (total 40, done 40, error 0, skipped 0, updateMessages 0) 2018-07-03 04:09:39 <1> susetest(6262) [zypp::plugin++] PluginExecutor.cc(send):85 +++++++++++++++ send PluginFrame[PLUGINEND](0){0} 2018-07-03 04:09:39 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(send):272 PluginScript[6281] /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py ->send PluginFrame[PLUGINEND](0){0} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(receive):426 PluginScript[6281] /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py <-PluginFrame[ACK](0){0} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(send):272 PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py ->send PluginFrame[PLUGINEND](0){0} 2018-07-03 04:09:40 <2> susetest(6262) [PLUGIN] PluginScript.cc(~PluginDumpStderr):75 ! INFO:root:PLUGINEND 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(receive):426 PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py <-PluginFrame[ACK](0){0} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginExecutor.cc(send):94 --------------- send PluginFrame[PLUGINEND](0){0} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(close):229 Close:PluginScript[6281] /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(send):272 PluginScript[6281] /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py ->send PluginFrame[_DISCONNECT](0){0} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(receive):426 PluginScript[6281] /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py <-PluginFrame[ACK](1){10} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(close):251 PluginScript[6281] /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py -> [0] Disconnect 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(close):229 Close:PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(send):272 PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py ->send PluginFrame[_DISCONNECT](0){0} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(receive):426 PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py <-PluginFrame[ACK](1){10} 2018-07-03 04:09:40 <1> susetest(6262) [zypp::plugin++] PluginScript.cc(close):251 PluginScript[6283] /usr/lib/zypp/plugins/commit/snapper.py -> [0] Disconnect ``` so could that be https://bugzilla.suse.com/show_bug.cgi?id=1099494 "zypper calls snapper, snapshot creation failed while snapper already running"? Keep in mind that the test module "gnucash" failing is merely a coincidence. https://openqa.opensuse.org/tests/700420/file/chromium-journal.log is the journal from the second log and it shows the same symptoms, snapper core dumps next to salt services while the failing test module is actually chromium. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1099886] snapperd segfault in destructor
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1099886 http://bugzilla.suse.com/show_bug.cgi?id=1099886#c6 --- Comment #6 from Stefan Hundhammer <shundhammer(a)suse.com> --- If it's not a completely incompatible lib or something like this, the only line in this backtrace that raises suspicion is IMHO this: #8 0x00007f8d630095f0 in snapper::logStreamClose(snapper::LogLevel, char const*, unsigned int, char const*, std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >*) () from /usr/lib64/libsnapper.so.4 One of the char const * might be 0. Or it might be a problem with the shutdown order; a string that was referenced via such a char const * might already be freed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1099752] New: Qt creator has no debug layout anymore
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=1099752 Bug ID: 1099752 Summary: Qt creator has no debug layout anymore Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: bernhard.friedrichs(a)web.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 775789 --> http://bugzilla.opensuse.org/attachment.cgi?id=775789&action=edit qt creator with no debug layout anymore When starting debugging with Qt creator the debugging layout is lost (this came with tumbelweed 25 June 2018, Qt creator 4.6.1) THAT IS HELL ON EARTH! Even when manually set Window->Views->Reset to default Layout the "debugger bar" below the source code does not appear anymore. Hint: when deleting .config/QtProject, start Qt (and forced to configure) it works ONCE (layout appears). Close Qt creator. Start again - debugging layout is lost. I have installed manually older versions down to 4.5.2 - same behavior!! (no problems on opensuse 15) So it must(?) be related to tumbleweed specific ... but what? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1096401] snapper: segfault found in openQA tests
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096401 http://bugzilla.suse.com/show_bug.cgi?id=1096401#c10 Dominique Leuenberger <dimstar(a)opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dimstar@opensuse. | |org) | --- Comment #10 from Dominique Leuenberger <dimstar(a)opensuse.org> --- A current coredump can be found in this test: https://openqa.opensuse.org/tests/702112/file/vlc-problem_detection_logs.ta… (the test module failing here was VLC, but in any case snapperd crashers are just the ones occupying the machine while writing out coredumps; so any module can fail the test) The tests have in commong that they install a package using pkcon install - and through libzypp have snapper modules firing up -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1096401] snapper: segfault found in openQA tests
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1096401 http://bugzilla.suse.com/show_bug.cgi?id=1096401#c9 Stefan Schubert <schubi(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dimstar(a)opensuse.org, | |schubi(a)suse.com Flags| |needinfo?(dimstar@opensuse. | |org) --- Comment #9 from Stefan Schubert <schubi(a)suse.com> --- (In reply to Dominique Leuenberger from comment #0) > While checking some logs on openQA, trying to find why so many tests are > failing, I stumbled over a segfault of snapper: > > Jun 07 02:18:14 susetest org.opensuse.Snapper[719]: terminate called after > throwing an instance of > 'boost::exception_detail::clone_impl<boost::exception_detail:: > error_info_injector<boost::lock_error> >' > Jun 07 02:18:14 susetest org.opensuse.Snapper[719]: what(): boost: mutex > lock failed in pthread_mutex_lock: Invalid argument > Jun 07 02:18:14 susetest systemd[1]: Started Process Core Dump (PID > 20684/UID 0). > Jun 07 02:18:15 susetest systemd-coredump[20685]: Process 18707 (snapperd) > of user 0 dumped core. > > TIME PID UID GID SIG COREFILE EXE > Thu 2018-06-07 02:09:35 EDT 2722 0 0 6 present /bin/login > Thu 2018-06-07 02:14:34 EDT 14648 0 0 6 present > /usr/sbin/snapperd > Thu 2018-06-07 02:15:58 EDT 16462 0 0 6 present > /usr/sbin/snapperd > Thu 2018-06-07 02:18:15 EDT 18707 0 0 6 present > /usr/sbin/snapperd > > This can explain why openQA has a hard time passing the tests, as the system > is pre-occupied writing coredumps > > The three snaperd coredumps are available in the openQA provided tarball > https://openqa.opensuse.org/tests/688332/file/gimp-problem_detection_logs. > tar.xz Hm, this file does not exist anymore. Could you please point us to it again ? Additional it would be nice if you point us to the point where it happens in this test. (The test is quite huge :-)) > > (directory coredumps) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1100181] New: WIFI PEAP deauthenticated with Reason: 1=UNSPECIFIED
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=1100181 Bug ID: 1100181 Summary: WIFI PEAP deauthenticated with Reason: 1=UNSPECIFIED Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: robert.lindvall(a)maxiv.lu.se QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build Identifier: I've been using my Lenovo X240 laptop on our work enterprise network with WPA/WPA2 Enterprise PEAP with the previous Opensuse LEAP releases without any problems. The laptop has the Intel Wifi card 7260, lspci output: 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 63) With Leap 15.0 the it tries to connect to the Enterprise network but never manages to connect. With Feodora 27 on another laptop it works fine (i.e password is correct). The enterprise wifi network has several Access Points with both 2.4 and 5GHz AP. I've tried to lock the Wifi to a specific access point, but it makes no difference. Reproducible: Always Steps to Reproduce: 1.Try to connect to Wifi Enterprise network with WPA2 PEAP without certificate Actual Results: dmesg output: [ 68.281256] wlan1: authenticate with 10:0e:7e:0e:1a:8b [ 68.293194] wlan1: send auth to 10:0e:7e:0e:1a:8b (try 1/3) [ 68.303440] wlan1: authenticated [ 68.306854] wlan1: associate with 10:0e:7e:0e:1a:8b (try 1/3) [ 68.308305] wlan1: RX AssocResp from 10:0e:7e:0e:1a:8b (capab=0x511 status=0 aid=8) [ 68.309557] wlan1: AP has invalid WMM params (CWmin/max=15/1023 for ACI 0), using defaults [ 68.310955] wlan1: associated [ 68.327567] wlan1: deauthenticated from 10:0e:7e:0e:1a:8b (Reason: 1=UNSPECIFIED) [ 68.614416] wlan1: authenticate with cc:e1:7f:12:95:0b [ 68.618343] wlan1: send auth to cc:e1:7f:12:95:0b (try 1/3) [ 68.626156] wlan1: authenticated [ 68.626827] wlan1: associate with cc:e1:7f:12:95:0b (try 1/3) [ 68.628279] wlan1: RX AssocResp from cc:e1:7f:12:95:0b (capab=0x511 status=0 aid=1) [ 68.628507] wlan1: AP has invalid WMM params (CWmin/max=15/1023 for ACI 0), using defaults [ 68.630169] wlan1: associated [ 68.640731] wlan1: deauthenticated from cc:e1:7f:12:95:0b (Reason: 1=UNSPECIFIED) I tried with a cheap RealTek based USB wifi dongle, and when trying to connect with that one it still behaves the same. In this forum post I've tried several suggestions but with always with same result. https://forums.opensuse.org/showthread.php/531972-Wifi-on-enterprise-networ… Connecting to a WPA2-PSK network works fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1099930] Notebook does reboot instead power off when pressing power button
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1099930 http://bugzilla.suse.com/show_bug.cgi?id=1099930#c7 --- Comment #7 from Thomas Hänig <haenig(a)cosifan.de> --- I am maybe paranoid, but I have some reservations in making details of the hardware (serial, number, uuid, MAC addresses) world wide known. Would it be possible to get your private gpg key to at least keep those details within a smaller audience? Replacing all occurances would be a bit of a problem as of e.g. the format of the hwinfo output. Thanks for your understanding. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1099757] Uyuni Internal Server Error Uploading Snippets (Reproducible)
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1099757 http://bugzilla.suse.com/show_bug.cgi?id=1099757#c9 Hubert Mantel <mantel(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Hubert Mantel <mantel(a)suse.com> --- (In reply to Bernd Helber from comment #5) > Investigating the Shell history > ------------------------------------------------------------------ > > > So far so good > > 68 2018-06-30 11:27:29 cd /var/lib/cobbler/snippets/ > 69 2018-06-30 11:27:33 ls -latr > 70 2018-06-30 11:27:37 unlink spacewalk > 71 2018-06-30 11:28:07 ln -s spacewalk > /var/lib/rhn/kickstarts/wizard/snippets/ > 72 > --------------------------------------------------------------------- > > Seems to be a Layer 8 User issue, not a Bug. sorry for bothering. Ok, I see. Thanks for checking. Will close as invalid then. Feel free to re-open in case the initial problem exists even after correcting the broken symlink. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1099930] Notebook does reboot instead power off when pressing power button
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1099930 http://bugzilla.suse.com/show_bug.cgi?id=1099930#c6 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |haenig(a)cosifan.de Flags| |needinfo?(haenig(a)cosifan.de | |) --- Comment #6 from Takashi Iwai <tiwai(a)suse.com> --- Thanks for testing. Then we need to report this to upstream. Could you give the detailed hardware information? Please attach at least the hwinfo output, and dmesg outputs from 4.16 (working) and 4.17 (broken) kernels. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1099930] Notebook does reboot instead power off when pressing power button
by bugzilla_noreply＠novell.com 05 Jul '18

05 Jul '18

http://bugzilla.suse.com/show_bug.cgi?id=1099930 http://bugzilla.suse.com/show_bug.cgi?id=1099930#c5 --- Comment #5 from Thomas Hänig <haenig(a)cosifan.de> --- None of both checked kernels: kernel-default-4.18.rc3-1.1.gd44a642.x86_64 kernel-default-4.17.4-1.1.g882c99b.x86_64 from those repositories worked for me. With both of those the older system now too refuses to switch off (everything else is unchanged there). The behaviour is always as follows.: - the OS is shutting down (unmounting, stopping, stopped, ...) - every LED besides the battery capacity LED is switched off (incl. so it seems the backlight of the screen) - approx. 5 seconds after this the notebook switches on again This behaviour is constant regardless of whether the battery is in or out, the notebook is in or out of the docking station, with or without mains power. -- You are receiving this mail because: You are on the CC list for the bug.

1 0