Bug 669019 - Anaconda reports "Network error" despite DHCP being successfully configured
Summary: Anaconda reports "Network error" despite DHCP being successfully configured
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 14
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 669016 (view as bug list)
Depends On: 663820 769145
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-12 13:19 UTC by Elie Bleton
Modified: 2012-08-16 22:18 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 22:18:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
anaconda.log (1.70 KB, text/x-log)
2011-01-12 13:19 UTC, Elie Bleton
no flags Details
syslog (127.17 KB, text/plain)
2011-01-12 13:20 UTC, Elie Bleton
no flags Details
anaconda.log.1 (1.64 KB, text/x-log)
2011-01-12 13:49 UTC, Elie Bleton
no flags Details
syslog.1 (115.33 KB, text/plain)
2011-01-12 13:49 UTC, Elie Bleton
no flags Details

Description Elie Bleton 2011-01-12 13:19:23 UTC
Created attachment 473016 [details]
anaconda.log

Description of problem:

During an automated text-mode anaconda installation (configured with a kickstart file), anaconda fails with the following error message :

" | Network Error |
There was an error configuring your network interface. "

At this point, the target computer have been configured with DHCP and can be pinged. 
Hitting "Retry" will destroy the networking configuration, rendering the machine unpingable.


However, the shell on pty/2 is not available, and sshd is not started (having given sshd in pxelinux append= parameter, and set "sshpw" entries in kickstart).


Version-Release number of selected component (if applicable):
Default anaconda with F14


How reproducible:
Transient error / happens about half the time on our setup (DHCP via dhcrelay).
PXE boot, which uses same DHCP server, works 100% of the time.


Steps to Reproduce:
1. (may or may not be relevant) Have subnets 10.0.0.0/24 and 10.0.1.0/24, dhcpd on 10.0.1.1, routing box sitting on both 10.0.0.1 and 10.0.1.254 with dhcrelay
2. use cobbler to pxe boot into anaconda
3. watch failure, or retry until it happens
  
Actual results:

Network fails about half the time, otherwise installs just fine

Expected results:

Installation proceeds everytime

Additional info:

Comment 1 Elie Bleton 2011-01-12 13:20:12 UTC
Created attachment 473017 [details]
syslog

Comment 2 Elie Bleton 2011-01-12 13:49:05 UTC
Created attachment 473022 [details]
anaconda.log.1

anaconda.log of network failure without pressing "retry" (network still up when pushing CTRL-Z in anaconda, manual sshd startup)

Comment 3 Elie Bleton 2011-01-12 13:49:44 UTC
Created attachment 473023 [details]
syslog.1

syslog of network failure without pressing "retry" (network still up when pushing CTRL-Z in anaconda, manual sshd startup)

Comment 4 Elie Bleton 2011-01-12 15:26:40 UTC
I'm starting to believe NetworkManager gives up on DHCP too quickly (40s), then DHCP finally completes and configure the network interface, but it fails because it timeouted. Maybe tuning the timeout somehow would fix this ?

Comment 5 Radek Vykydal 2011-01-13 15:08:58 UTC
(In reply to comment #4)
> I'm starting to believe NetworkManager gives up on DHCP too quickly (40s), then
> DHCP finally completes and configure the network interface, but it fails
> because it timeouted. Maybe tuning the timeout somehow would fix this ?

Yes, it definitely seems like DHCP timeout problem. Anaconda used to have dhcptimeout boot option, but since we moved to NetworkManager it is under its control (45s).

Comment 6 Radek Vykydal 2011-01-13 15:11:46 UTC
*** Bug 669016 has been marked as a duplicate of this bug. ***

Comment 7 henry 2011-09-02 18:40:13 UTC
Also observing not being about to extend the 45s timeout with 'dhcptimeout=X' as a kopt.

This is in RHEL6.1 -- rather annoying since the I need ~180 for a successful build over an extended network.

Any idea if this got patched somewhere else?

Comment 8 Radek Vykydal 2011-09-05 10:54:10 UTC
(In reply to comment #7)

> 
> Any idea if this got patched somewhere else?

There is a corresponding NetworkManager bug 663820.

Comment 9 Fedora End Of Life 2012-08-16 22:18:28 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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