Bug 902086 - Autoyast Stage2 segfaults when using add-on section
Autoyast Stage2 segfaults when using add-on section
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: AutoYaST
13.2 RC 1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: AutoYaST Maintainers
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-21 16:42 UTC by LNT Sysadmin
Modified: 2014-11-03 15:26 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
y2log of second stage showing segfault at the end (208.98 KB, text/plain)
2014-10-21 16:42 UTC, LNT Sysadmin
Details
profile with 10 min delay to force repo refresh (18.14 KB, text/xml)
2014-10-22 08:50 UTC, Joschi Brauchle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description LNT Sysadmin 2014-10-21 16:42:12 UTC
Created attachment 610825 [details]
y2log of second stage showing segfault at the end

Running auto installation with an add-on section defined results in a broken installation as the second installation stage segfaults, please see y2log of second stage attached.

I did two installations, with this diff between xmls:
-------
--- test.xml    2014-10-21 17:05:15.000000000 +0200
+++ test.xml.broken     2014-10-21 17:05:04.000000000 +0200
@@ -4,7 +4,14 @@
    <add-on>
-    <add_on_products config:type="list"/>
+    <add_on_products config:type="list">
+      <listentry>
+ 
<media_url><![CDATA[http://download.opensuse.org/repositories/home:/lnt-sysadmin:/tools/openSUSE_13.2/]]></media_url> 

+        <name>OpenSUSE13.2_HTTP_OBS:lnt-sysadmin:tools</name>
+        <product>OpenSUSE13.2 HTTP OBS:lnt-sysadmin:tools</product>
+        <product_dir>/</product_dir>
+      </listentry>
+    </add_on_products>
    </add-on>
-------
Only the installation *with* the add-on section specified is broken!
Comment 1 Stefan Schubert 2014-10-22 07:32:51 UTC
Could you please attach your autoinst.xml too ? Thanks !
Comment 2 Joschi Brauchle 2014-10-22 08:50:53 UTC
Created attachment 610933 [details]
profile with 10 min delay to force repo refresh

I have narrowed down the problem some more:
The installation runs *FINE* if and only if the last refresh of all product repositories was less than 10 minutes ago.

In this case, the repo refresh is skipped and no segfault occurs!!

In the attached y2log one can see the line
---------
[zypp++] RepoManager.cc(checkIfToRefreshMetadata):919 last refresh = 11.3333 minutes ago
---------
which forces a refresh, which then segfaults.
Comment 3 Stefan Schubert 2014-10-22 09:28:29 UTC
Michl, looks like a libzypp "problem". Could you please have a look ?
Comment 4 Joschi Brauchle 2014-10-22 09:55:35 UTC
For reference, this old openSUSE 11.0 bug has an closely related crash:
https://bugzilla.novell.com/show_bug.cgi?id=685890#c3

Also, there is a bug related to sw_single crashing here
https://bugzilla.novell.com/show_bug.cgi?id=887051
which is a dupe of 
https://bugzilla.novell.com/show_bug.cgi?id=866692#c4

This all seems to be related!
Comment 5 Michael Andres 2014-10-22 11:54:09 UTC
(In reply to Stefan Schubert from comment #3)
> Michl, looks like a libzypp "problem". Could you please have a look ?

According to the backtrace in the log, libproxy is loading the KDE module and it crashes in libkdecore:

> vvvvvvvvvv----------------------------------------
> [bt]: (0) /usr/lib64/libkdecore.so.5 : +0x9f21e [0x7f486f1bb21e]
> [bt]: (1) /lib64/ld-linux-x86-64.so.2 : +0xe92a [0x7f489f02092a]
> [bt]: (2) /lib64/ld-linux-x86-64.so.2 : +0xea13 [0x7f489f020a13]
> [bt]: (3) /lib64/ld-linux-x86-64.so.2 : +0x12b48 [0x7f489f024b48]
> [bt]: (4) /lib64/ld-linux-x86-64.so.2 : +0xe7e4 [0x7f489f0207e4]
> [bt]: (5) /lib64/ld-linux-x86-64.so.2 : +0x1233b [0x7f489f02433b]
> [bt]: (6) /lib64/libdl.so.2 : +0x102b [0x7f489d99202b]
> [bt]: (7) /lib64/ld-linux-x86-64.so.2 : +0xe7e4 [0x7f489f0207e4]
> [bt]: (8) /lib64/libdl.so.2 : +0x15dd [0x7f489d9925dd]
> [bt]: (9) /lib64/libdl.so.2 : dlopen+0x31 [0x7f489d9920c1]
> [bt]: (10) /usr/lib64/libmodman.so.1 : libmodman::module_manager::load_file(std::string, bool)+0x375 [0x7f48790bbf25]
> [bt]: (11) /usr/lib64/libmodman.so.1 : libmodman::module_manager::load_dir(std::string, bool)+0x253 [0x7f48790bc2b3]
> [bt]: (12) /usr/lib64/libproxy.so.1 : +0xce06 [0x7f487aacde06]
> [bt]: (13) /usr/lib64/libproxy.so.1 : px_proxy_factory_new+0x1b [0x7f487aace9bb]
> [bt]: (14) /usr/lib64/libzypp.so.1429 : zypp::media::ProxyInfoLibproxy::ProxyInfoLibproxy()+0x261 [0x7f487bbaebb1]
> [bt]: (15) /usr/lib64/libzypp.so.1429 : zypp::media::ProxyInfo::ProxyInfo()+0x1c [0x7f487bbd8bdc]

So this seems to be another duplicate of bug#866692 which should be fixed with yast2-3.1.92.


@LNT Sysadmin: If your yast version is older, a workaround should be explicitly exclude libproxy1-config-kde4 from being installed.
Comment 6 Joschi Brauchle 2014-10-22 16:27:59 UTC
(this is my personal account vs LNTSysadmin for my group)

I am using current factory for autoinstallation.

Hence it should actually be yast2-3.1.108-1.2.x86_64.rpm from here: http://download.opensuse.org/factory/repo/oss/suse/x86_64/ 

Is there a way to see the yast version from y2log?
Comment 7 Joschi Brauchle 2014-10-22 16:59:24 UTC
I can confirm that autoinstallation succeeds when adding:
-------------
  <software>
    <remove-packages config:type="list">
      <package>libproxy1-config-kde4</package>
    </remove-packages>
  </software>
-------------

Does the yast2 startup script also run the second stage of the autoinstall process? Somehow the autoinstaller is still affected by bug#866692...
Comment 8 Michael Andres 2014-10-23 12:56:33 UTC
Passing the question back to yast/autoyast.
Comment 9 Stefan Schubert 2014-10-29 13:39:37 UTC
(In reply to Joschi Brauchle from comment #7)

> Does the yast2 startup script also run the second stage of the autoinstall
> process? Somehow the autoinstaller is still affected by bug#866692...

No, unfortunately not.
Comment 10 Stefan Schubert 2014-11-03 09:15:46 UTC
I have tried it several times but I have not been able to reproduce that bug.
Could you please try it with patch in file
/usr/lib/systemd/system/YaST2-Second-Stage.service ?

 [Service]
 Type=oneshot
-Environment=SYSTEMCTL_OPTIONS=--ignore-dependencies TERM=linux
+Environment=SYSTEMCTL_OPTIONS=--ignore-dependencies TERM=linux PX_MODULE_PATH=""
 # Workaround of bug in plymouth --> using deactivate option
 # in second boot stage in order to start ncurses yast correctly
 # (bnc#886488)

Thanks !
Comment 11 Joschi Brauchle 2014-11-03 10:10:47 UTC
(In reply to Stefan Schubert from comment #10)
> I have tried it several times but I have not been able to reproduce that bug.
> Could you please try it with patch in file
> /usr/lib/systemd/system/YaST2-Second-Stage.service ?
> 
>  [Service]
>  Type=oneshot
> -Environment=SYSTEMCTL_OPTIONS=--ignore-dependencies TERM=linux
> +Environment=SYSTEMCTL_OPTIONS=--ignore-dependencies TERM=linux
> PX_MODULE_PATH=""
>  # Workaround of bug in plymouth --> using deactivate option
>  # in second boot stage in order to start ncurses yast correctly
>  # (bnc#886488)
> 
> Thanks !

Thank you, adding PX_MODULE_PATH="" indeed fixes the problem.

I could provide a snapshot (end of first stage) of a 13.2 auto installation showing the problem. When continuing w/o above change, Yast segfaults in second stage.
Comment 12 Stefan Schubert 2014-11-03 15:26:06 UTC
Fixed in
https://github.com/yast/yast-installation/pull/242