Bug 371821

Summary: boot command line "ip=xx.xx.xx.xx" ignored, still defaults to DHCP
Product: [Fedora] Fedora Reporter: george.b.milner
Component: anacondaAssignee: David Cantrell <dcantrell>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: bolek-vendor
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-26 01:13:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
syslog messages from DHCP server none

Description george.b.milner 2007-11-08 20:56:50 UTC 
Description of problem: anaconda ignores static IP information on the command line.


Version-Release number of selected component (if applicable): anaconda installer
11.3.0.50


How reproducible: Always ( only tried on D830 and D600 laptops so far )


Steps to Reproduce:

1. boot from usb device with diskboot.img on it
2. "vmlinuz initrd=initrd.img text ks=http://192.168.0.1/ks.cfg ksdevice=link
ip=192.168.0.2 netmask=255.255.255.0 noipv6
3.
  
Actual results:
"Sending request for IP information for eth0...", I waited 10 minutes and
anaconda did not revert back to the "interactive" screen.

Log screen shows eth0 link is up.


Expected results: A kickstart install.


Additional info:
I tried with/without ksdevice=[link|eth0|eth1]
Works in FC6 and FC7
Comment 1 Boleslaw Ciesielski 2007-11-25 23:58:32 UTC 
I am seeing the same problem but only with x86_64. The i386 version works fine.

In addition, the kickstart fails as described above even if I have working DHCP
server and use it for installation. Attached is a portion of the syslog from the
machine that's running the DHCP server. The first DHCPDISCOVER is from the PXE
boot and it works fine. The second and subsequent DHCPDISCOVER (after the tftp
messages) are from anaconda. It seems to be stuck in a DHCPDISCOVER loop and
never issues DHCPREQUEST, even though the server is replying with DHCPOFFER.
Comment 2 Boleslaw Ciesielski 2007-11-25 23:59:33 UTC 
Created attachment 268431 [details]
syslog messages from DHCP server
Comment 3 Alexandre Oliva 2007-11-26 01:13:42 UTC 

*** This bug has been marked as a duplicate of 374271 ***