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
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.
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
*** Bug 735355 has been marked as a duplicate of this bug. ***
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.
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.
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.
Just for completeness the duplicate bug #735355 from comment #3 is on ppc64.
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.
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
(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
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.
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.
Discussed at the 2011-09-09 blocker review meeting, and we agreed on the above.
This should be fixed in F17.
as this blocks s390x install we'd probably need it in the f16 build or else f16 will never work on s390?
(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.
Retested with anaconda-17.29. Installation finished without any traceback, so closing this bug as fixed.