Red Hat Bugzilla – Bug 471382
NetworkManager doesn't get IP address when starting with kickstart file
Last modified: 2013-01-09 23:55:32 EST
Description of problem:
NetworkManager doesn't get an IP address when anaconda is started with a kickstart file. After NetworkManager times out, if you hit retry, it works.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. PXE install F10/Rawhide from kickstart
Wait while NetworkManager times out
NetworkManager gets IP address and we move on
Results from Ctrl-Alt-F4:
<29>Nov 13 12:39:02 NetworkManager: <info> (eth0): device state change: 1 -> 2
<29>Nov 13 12:39:02 NetworkManager: <info> (eth0): bringing up device.
<6>eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
<29>Nov 13 12:39:02 NetworkManager: <info> (eth0): preparing device.
<29>Nov 13 12:39:02 NetworkManager: <info> (eth0): deactivating device (reason: 2).
<29>Nov 13 12:39:02 NetworkManager: <info> (eth0): carrier now ON (device state 2)
<29>Nov 13 12:39:02 NetworkManager: <info> (eth0): device state change: 2 -> 3
Created attachment 323445 [details]
Kickstart file used
Created attachment 323446 [details]
PXE configuration file
Me too, with r8169 (possibly 471375 is a dupe?)
For me this happens on preupgrade from F9, which is likely to be a fairly common setup. I'll attach a photo of the messages VT while anaconda was waiting
Created attachment 323708 [details]
Photo of logs while waiting for network
Jonathan, can you attach the full anaconda log set? anaconda.log, sys.log etc from /tmp/ ? Also, what nic are you using? I think this is specific to realtek nics (and things emulating them). I can easily reproduce in kvm when emulating a realtek, but it just works fine when emulating an e1000.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
Created attachment 325305 [details]
syslog during installation
I'm having the same problem with r8169. I'm attaching the syslog, as sent to a remote log server (with the "logging" kickstart directive).
Is there a workaround to do standard /etc/init.d/network initialization instead of NetworkManager? I can't easily plug a keyboard into 20 different machines. Thanks!
Created attachment 325315 [details]
I am attaching the full logs from /tmp/syslog and /tmp/anaconda.log. Please let me know if there are any other files that would be helpful.
Created attachment 325316 [details]
amcnabb: the current workaround is to modify your guest to use the virtio or e1000 driver (instead of rlt8139). To use the virtio driver ...
1) Edit your guest xml configuration
# virsh edit <guest>
2) Add "<model type='virtio'/>" to your network interface. For example ...
3) Save and exit
4) You may need to reboot/restart your guest for the changes to take affect
jlaska: I might have trouble getting the virtio or e1000 drivers to work with Realtek hardware. :)
Is there some way to get Anaconda to go back to what it used to do instead of NetworkManager, or some other workaround? I have a stack of headless machines that I can't install without a keyboard and monitor. If I had a choice, I would pick a higher severity than "medium". Thanks!
amcnabb: ah apologies, I'm hitting this bug in all my kvm guests ... forgot that rtl8139 isn't specific to virtualization :)
There is no way to have anaconda not use NetworkManager.
Another workaround I found was to not provide any networking parameters on boot, but instead let NetworkManager guess. That worked better than providing ksdevice=link ip=dhcp (assuming these system only have 1 NIC). Not sure if that helps.
I just tried commenting out "network --bootproto=dhcp" from my kickstart script, but that didn't seem to work either. It was worth a try.
the workarround for me (on real hardware) was just to retry when asked, and then it worked. I'm not 100% sure that the network actually worked, since this was using preupgrade which shouldn't have needed the network.
Bradley, clicking on retry does make it work, but it's not a very good workaround since it requires a keyboard. I can confirm that the network does work when you click retry (my install was completely over the network).
This looks like a problem with the rtl8139 driver. I can't reproduce the problem on my hardware, but I don't have an rtl8139 either.
It's dead-easy to reproduce when using say kvm or qemu which by default emulate a rtl card. I've had to switch all my virt images to use e1000 emulated or virtio to get around this issue.
I'm experiencing similar problems with cd-rom+kickstart installs on a kvm virtual machine (used as a staging sandbox) ; same symptoms.
Either when ks.cfg asks for the network to be configured, or when the kernel command line receives a ks.cfg location over the network (ks=http://blah/blah/blah), the NetworkManager timeout problem shows up (albeit earlier on in the latter context).
I've rebuilt an updated boot.iso with anaconda, the problem seems to be gone. So I'd take it that there was at least some mishap with nm or the network device driver.
The trouble seems to be only half gone though, since at the moment I only succeed with the ks=http:// method. Injecting a ks.cfg file onto the cdrom as I've always done so far seems to stumble on the same problem.
Noteworthy updated packages present in the half-successful boot.iso file:
For what it's worth, the updated iso for x86_64 is at:
Corresponding pxe files at:
Hope this helps,
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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:
From my experience, this was fixed in Fedora 11. Has any one still been having this problem?
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.