Bug 471382 - NetworkManager doesn't get IP address when starting with kickstart file
NetworkManager doesn't get IP address when starting with kickstart file
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-13 07:47 EST by Jonathan Dieter
Modified: 2013-01-09 23:55 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:50:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Kickstart file used (434 bytes, text/plain)
2008-11-13 07:48 EST, Jonathan Dieter
no flags Details
PXE configuration file (1.39 KB, text/plain)
2008-11-13 07:50 EST, Jonathan Dieter
no flags Details
Photo of logs while waiting for network (1.10 MB, image/jpeg)
2008-11-15 22:42 EST, Bradley
no flags Details
syslog during installation (20.66 KB, text/plain)
2008-12-01 16:47 EST, Andrew McNabb
no flags Details
/tmp/syslog (43.15 KB, text/plain)
2008-12-01 18:20 EST, Andrew McNabb
no flags Details
/tmp/anaconda.log (12.11 KB, application/octet-stream)
2008-12-01 18:20 EST, Andrew McNabb
no flags Details

  None (edit)
Description Jonathan Dieter 2008-11-13 07:47:19 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):
anaconda-11.4.1.57-1.

How reproducible:
Always

Steps to Reproduce:
1. PXE install F10/Rawhide from kickstart
  
Actual results:
Wait while NetworkManager times out

Expected results:
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
Comment 1 Jonathan Dieter 2008-11-13 07:48:11 EST
Created attachment 323445 [details]
Kickstart file used
Comment 2 Jonathan Dieter 2008-11-13 07:50:31 EST
Created attachment 323446 [details]
PXE configuration file
Comment 3 Bradley 2008-11-15 22:40:57 EST
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
Comment 4 Bradley 2008-11-15 22:42:26 EST
Created attachment 323708 [details]
Photo of logs while waiting for network
Comment 5 Jesse Keating 2008-11-19 15:23:47 EST
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.
Comment 6 Bug Zapper 2008-11-26 00:18:20 EST
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Andrew McNabb 2008-12-01 16:47:23 EST
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!
Comment 8 Andrew McNabb 2008-12-01 18:20:13 EST
Created attachment 325315 [details]
/tmp/syslog

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.
Comment 9 Andrew McNabb 2008-12-01 18:20:39 EST
Created attachment 325316 [details]
/tmp/anaconda.log
Comment 10 James Laska 2008-12-02 08:28:43 EST
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 ... 

    <interface type='bridge'>
      <mac address='XX:XX:XX:XX:XX:XX'/>
      <source bridge='br0'/>
      <target dev='vnet2'/>
      <model type='virtio'/>
    </interface>

3) Save and exit
4) You may need to reboot/restart your guest for the changes to take affect
Comment 11 Andrew McNabb 2008-12-02 10:26:21 EST
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!
Comment 12 James Laska 2008-12-02 10:38:24 EST
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.
Comment 13 Andrew McNabb 2008-12-02 11:03:20 EST
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.
Comment 14 Bradley 2008-12-02 15:20:26 EST
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.
Comment 15 Andrew McNabb 2008-12-02 22:15:35 EST
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).
Comment 16 David Cantrell 2008-12-04 19:52:01 EST
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.
Comment 17 Jesse Keating 2008-12-04 20:17:12 EST
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.
Comment 18 Emmanuel Thomé 2009-01-05 19:00:04 EST
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:

kernel-2.6.27.9-159.fc10.x86_64.rpm
NetworkManager-0.7.0-0.12.svn4326.fc10.x86_64.rpm

For what it's worth, the updated iso for x86_64 is at:
http://www.loria.fr/~thome/vrac/boot-iso-f10-updated.iso

Corresponding pxe files at:
http://www.loria.fr/~thome/vrac/pxeboot.tar

Hope this helps,

E.
Comment 19 Bug Zapper 2009-11-18 03:50:58 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Andrew McNabb 2009-11-18 11:16:51 EST
From my experience, this was fixed in Fedora 11.  Has any one still been having this problem?
Comment 21 Bug Zapper 2009-12-18 01:50:13 EST
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.

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