Red Hat Bugzilla – Bug 669019
Anaconda reports "Network error" despite DHCP being successfully configured
Last modified: 2012-08-16 18:18:28 EDT
Created attachment 473016 [details]
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
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
Network fails about half the time, otherwise installs just fine
Installation proceeds everytime
Created attachment 473017 [details]
Created attachment 473022 [details]
anaconda.log of network failure without pressing "retry" (network still up when pushing CTRL-Z in anaconda, manual sshd startup)
Created attachment 473023 [details]
syslog of network failure without pressing "retry" (network still up when pushing CTRL-Z in anaconda, manual sshd startup)
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 ?
(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).
*** Bug 669016 has been marked as a duplicate of this bug. ***
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?
(In reply to comment #7)
> Any idea if this got patched somewhere else?
There is a corresponding NetworkManager bug 663820.
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: