Bug 733680 - DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper ex...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
16
s390x Linux
high Severity high
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
RejectedNTH
:
Depends On:
Blocks: ZedoraTracker F16Betas390x 739846 788663
  Show dependency treegraph
 
Reported: 2011-08-26 09:40 EDT by Jan Stodola
Modified: 2012-07-02 04:44 EDT (History)
6 users (show)

See Also:
Fixed In Version: anaconda-17.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 788663 (view as bug list)
Environment:
Last Closed: 2012-07-02 04:44:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda traceback (99.81 KB, text/plain)
2011-08-26 09:40 EDT, Jan Stodola
no flags Details

  None (edit)
Description Jan Stodola 2011-08-26 09:40:46 EDT
Created attachment 520093 [details]
anaconda traceback

Description of problem:
When installing F16 for s390x, following traceback appears in stage2, after reinitializing all disks:

anaconda 16.15 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 281, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 183, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 241, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 244, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/network.py", line 175, in getActiveNetDevs
    nm = bus.get_object(isys.NM_SERVICE, isys.NM_MANAGER_PATH)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/network.py", line 101, in getDefaultHostname
    for dev in getActiveNetDevs():
  File "/usr/lib64/python2.7/site-packages/pyanaconda/textw/network_text.py", line 29, in __call__
    hname = network.getDefaultHostname(anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/text.py", line 534, in display_step
    rc = win(self.screen, self.anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 377, in dispatch
    rc = self.anaconda.intf.display_step(self.step)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/text.py", line 508, in run
    self.anaconda.dispatch.dispatch()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 319, in run
    self.anaconda.intf.run(self.anaconda)
  File "/usr/sbin/anaconda", line 770, in <module>
    anaconda.dispatch.run()
DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1

Version-Release number of selected component (if applicable):
anaconda-16.15

How reproducible:
always

Steps to Reproduce:
1. start installation in x3270 terminal
2. in linuxrc, enter all required values
3. connect via ssh to continue with the installation
4. continue in text mode (there wasn't even dialog to start VNC server...)
  
Actual results:
traceback after reinitializing disks

Expected results:
no traceback, successful installation
Comment 1 Radek Vykydal 2011-08-30 11:11:01 EDT
Anaconda doesn't seem to be able to run NetworkManager

13:27:30,438 INFO loader: restarting NetworkManager
13:27:30,463 ERR loader: iface_restart_NetworkManager (529): No such file or directory
13:27:30,463 ERR loader: failed to restart NetworkManager

13:31:35,0 NOTICE dbus: [system] Activating service name='org.freedesktop.NetworkManager' (using servicehelper)
13:31:35,0 NOTICE dbus: [system] Activated service 'org.freedesktop.NetworkManager' failed: Launch helper exited with unknown return code 1
13:32:00,0 NOTICE dbus: [system] Activating service name='org.freedesktop.NetworkManager' (using servicehelper)
13:32:00,0 NOTICE dbus: [system] Activated service 'org.freedesktop.NetworkManager' failed: Launch helper exited with unknown return code 1

Normally, in rawhide and F16, NM should be started by systemd, and restarted in anaconda's loader. It is quite a recent change (bug #727951), formerly NM used to be started by anaconda in loader (at the point where now it is just restarted calling systemctl) if it is not found running.
Comment 2 Jan Stodola 2011-08-31 09:41:45 EDT
There are also some assertion failures related so systemd showing on console:

in stage1:
...
13:40:12,452 INFO loader: restarting NetworkManager 
Assertion 'bus' failed at src/systemctl.c:1566, function start_unit(). Aborting.
 
13:40:12,487 ERR loader: iface_restart_NetworkManager (529): No such file or dir
ectory 
13:40:12,487 ERR loader: failed to restart NetworkManager 
...

If I try to run 'systemctl -a' in another ssh session during the install, the process is aborted:
-bash-4.2# systemctl -a
Assertion 'bus' failed at src/systemctl.c:420, function list_units(). Aborting.
Aborted
Comment 3 Martin Banas 2011-09-02 09:28:05 EDT
*** Bug 735355 has been marked as a duplicate of this bug. ***
Comment 4 Chris Lumens 2011-09-05 15:27:11 EDT
The "no such file or directory" part makes me wonder if we're not including, removing, or otherwise missing some newly critical thing NM needs from our lorax template.
Comment 5 Radek Vykydal 2011-09-06 04:05:27 EDT
This is s390x specific. I'm not sure how are the composes of images keeping up with other architectures. Seems like systemd integration problem to me. One possible fix would be to start NM as we used to before (fork the daemon) if we don't find it running up by systemd, but I'd strongly prefer to fix this on level of systemd configuration. I think I'll have to put my hands on some of the machines.
Comment 6 Radek Vykydal 2011-09-06 06:42:48 EDT
s390 is still using linuxrc.s390, so no systemd. In this case, considering this feature http://fedoraproject.org/wiki/Anaconda/Features/RemoveLinuxrcS390 being targeted to F17, the fix for F16 would probably be the first option from comment #5.
Comment 7 Dan Horák 2011-09-07 14:09:08 EDT
Just for completeness the duplicate bug #735355 from comment #3 is on ppc64.
Comment 8 Radek Vykydal 2011-09-08 03:52:41 EDT
Yeah, I was thinking about undupeing it, I believe the root cause is different there, compare:

s390x (this bug):
13:27:30,438 INFO loader: restarting NetworkManager
13:27:30,463 ERR loader: iface_restart_NetworkManager (529): No such file or
directory
13:27:30,463 ERR loader: failed to restart NetworkManager

and:

ppc (bug 735355):
09:07:33,754 INFO loader: restarting NetworkManager
09:07:33,871 ERR loader: failed to restart NetworkManager with status 1
09:07:33,871 ERR loader: failed to restart NetworkManager

Also ppc64 case is a newer (a bit more destabilized) anaconda version and compose I think.
Comment 9 Dan Horák 2011-09-08 04:19:08 EDT
The following is end of anaconda.log from s390x compose that consist of anaconda-16.16-1.fc16.dh.1 (the only change is enabled debuginfo) + dracut-013-8.fc16 + systemd-35-1.fc16 + s390x rawhide-20110831 tree (corresponds to F-16 alpha in primary arch)

...
18:05:09,178 DEBUG loader: Saving module squashfs 
18:05:09,179 DEBUG loader: probing buses 
18:05:09,271 DEBUG loader: waiting for hardware to initialize 
18:05:10,117 INFO loader: restarting NetworkManager 
18:05:10,151 ERR loader: iface_restart_NetworkManager (529): No such file or dir
ectory 
18:05:10,151 ERR loader: failed to restart NetworkManager 
18:05:10,199 INFO loader: No iBFT table detected. 
18:05:10,199 INFO loader: only have one network device: eth0
Comment 10 Dan Horák 2011-09-08 04:21:42 EDT
(In reply to comment #9)
> The following is end of anaconda.log from s390x compose that consist of
> anaconda-16.16-1.fc16.dh.1 (the only change is enabled debuginfo) +
> dracut-013-8.fc16 + systemd-35-1.fc16 + s390x rawhide-20110831 tree
> (corresponds to F-16 alpha in primary arch)

and built with pungi 2.9 and lorax 16.4.2
Comment 11 Radek Vykydal 2011-09-09 09:47:58 EDT
Patch is here:

https://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00062.html

Proposing as F16 Beta NTH. The fix should be safe, it only pulls back (specifically for s390) what was removed in f16 alpha with bug 727951.
Comment 12 Adam Williamson 2011-09-09 14:21:24 EDT
I believe this should be marked as blocking F16Betas390x, rather than F16Beta-accepted. Though there is the question of what we do with anaconda fixes for secondary arches during freeze periods, which I'm not sure has been addressed.
Comment 13 Adam Williamson 2011-09-09 14:23:59 EDT
Discussed at the 2011-09-09 blocker review meeting, and we agreed on the above.
Comment 14 Radek Vykydal 2011-10-07 08:46:40 EDT
This should be fixed in F17.
Comment 15 Adam Williamson 2011-10-07 11:48:50 EDT
as this blocks s390x install we'd probably need it in the f16 build or else f16 will never work on s390?
Comment 16 Dan Horák 2011-10-07 11:57:23 EDT
(In reply to comment #15)
> as this blocks s390x install we'd probably need it in the f16 build or else f16
> will never work on s390?

Ideally yes, we need to find the right procedure how and when apply fixes for secondary arches, it could be for example a post-GA update. Secondary arches can use ad-hoc patched packages (and actually use few of them) in their repos that don't have a matching counterpart in primary.
Comment 17 Jan Stodola 2012-07-02 04:44:51 EDT
Retested with anaconda-17.29. Installation finished without any traceback, so closing this bug as fixed.

Note You need to log in before you can comment on or make changes to this bug.