Bug 519014 - upgrading from f10 to rawhide install fails during initializing eth0
Summary: upgrading from f10 to rawhide install fails during initializing eth0
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: David Cantrell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-24 15:35 UTC by Don Zickus
Modified: 2009-09-17 00:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-17 00:40:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
syslog of the install (47.78 KB, text/plain)
2009-08-24 15:36 UTC, Don Zickus
no flags Details
the anaconda.log of the install process (27.77 KB, text/plain)
2009-08-24 15:37 UTC, Don Zickus
no flags Details

Description Don Zickus 2009-08-24 15:35:50 UTC
Description of problem:

I was happily following the graphical anaconda screens to upgrade to rawhide, when it asked which nic to use.  So I just selected eth0 and left the defaults for dhcp and the other checkbox, then hit OK.

A few seconds later anaconda barfed.  This time I was able to figure out where the logs are kept and saved them to be attached here.

I tried to save the logs using Bugzilla, but that gave me a -3 error.  Tried again locally, but that hung forever.  Finally managed to save them from the shell prompt. 

Didn't realize how 'raw' rawhide was these days.  I thought with the alpha release coming up, things were more stable.  I should have known better.

Version-Release number of selected component (if applicable):
whatever was available for the morning of 08/24/09 (EST)

How reproducible:
don't know.


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Don Zickus 2009-08-24 15:36:35 UTC
Created attachment 358473 [details]
syslog of the install

Comment 2 Don Zickus 2009-08-24 15:37:18 UTC
Created attachment 358474 [details]
the anaconda.log of the install process

Comment 3 Chris Lumens 2009-08-24 15:47:22 UTC
It'd be helpful to know what the save-to-bugzilla error was, though it's probably related to this networking problem.  I'd still like to make it a little more robust in the face of these sorts of issues since it's the bug reporting system.

Comment 4 Don Zickus 2009-08-24 17:12:20 UTC
Ok, so I reproduced the problem again and here is my handtyped message of what I see:

--->
Unable to File Bug

Your bug could not be filed due to the following error when communicating with bugzilla:

Error communicating with bug system: [Errno -3]
Temporary failure in name resolution
--->

So it looks like you may be right, bugzilla can't work if the network init failed.

Comment 5 Chris Lumens 2009-08-25 15:09:47 UTC
Traceback (most recent call first):
  File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
  File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/anaconda/network.py", line 769, in bringUp
    state = props.Get(isys.NM_SERVICE, "State")
  File "/usr/lib/anaconda/iw/netconfig_dialog.py", line 243, in _ok
    haveNet = self.network.bringUp()
  File "/usr/lib/anaconda/iw/netconfig_dialog.py", line 178, in run
    if self._ok():
  File "/usr/lib/anaconda/gui.py", line 1003, in enableNetwork
    ret = net.run()
  File "/usr/lib/anaconda/yuminstall.py", line 1066, in doBackendSetup
    if not anaconda.intf.enableNetwork():
  File "/usr/lib/anaconda/backend.py", line 271, in doBackendSetup
    if anaconda.backend.doBackendSetup(anaconda) == DISPATCH_BACK:
  File "/usr/lib/anaconda/dispatch.py", line 204, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 127, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1201, in nextClicked
    self.anaconda.dispatch.gotoNext()
DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Comment 6 David Cantrell 2009-09-17 00:40:33 UTC
I remember things changing in NetworkManager around the end of August, so I think this is fallout from that.  I cannot reproduce this problem with an F-10 system upgrading to the latest rawhide.


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