Bug 88714

Summary: PXE installer apparently does not setup network interface
Product: [Retired] Red Hat Linux Reporter: Mark Himsley <redhat.com>
Component: installerAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-24 18:44:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Mark Himsley 2003-04-12 12:40:01 UTC
Description of problem:

Having just downloaded the 3 ISOs of shrike I did the usual thing of putting  
shrike-i386-disc1.iso/images/pxeboot/{vmlinux,initrd.img} into a TFTP server 
along with a config file in pxelinux.cfm and setting up the DHCP server.

This all worked as I would expect and the installer started up.

I (err, obviously) wanted to do a network install so in the installed I 
Language: English
Keyboard: UK
Method:   NFS
Network Device: eth0 (as this box has two network interfaces)

At this point I expected to be asked whether to use DHCP or to enter some 
parameters for the interface. I wasn't. The next screen I see is the 'NFS 
setup' dialog where I am asked for the NFS server & Red Hat directory. If I 
enter valid values into there (either IP address or hostname for the server) I 
*always* get the result "That directory could not be mounted from the server".

Looking further into this problem I studied the messages on virtual terminal 4. 
I can see that the kernel detects both the network interfaces correctly, giving 
the on-motherboard interface eth0 - which is good 'cause that's where the 
network needs to be for the pxelinux.0 boot. But close to the end of the 
messages it says:

* using interface eth0
* doing kickstart... setting up
* result of pumpSetupInterface is SIOCSIFNETMASK: Cannot assign requested 
* reverse name lookup failed
* going to do nfsGetSetup
* mounting nfs path

So. I decided to snort my network to see if I could see any DHCP requests from 
the client while it was initialising the network interface. I saw no requests. 
I can only imagine that something is going wrong with the installer and its not 
setting up the network interface.

Currently I cannot see how to get round this problem, except by throwing extra 
hardware at the client box. But if that's the solution then its a major step 
back from previous versions of RedHat Linux.

Comment 1 Jeremy Katz 2003-04-14 16:49:37 UTC
What is your kernel command line?

Comment 2 Mark Himsley 2003-04-14 21:45:32 UTC
I can't see the exact kernel command line as it wizzes past too quickly but the 
pxelinux.cfg file I am using includes the following, I hope this includes 
enough info for you.

default text
prompt 1
timeout 600
label text
  kernel /rh9.0/vmlinuz
  append initrd=/rh9.0/initrd.img lang= text devfs=nomount ramdisk_size=8192 

Comment 3 Mark Himsley 2003-04-14 21:47:20 UTC
Sorry about the line break in the 'append' line above - the nofb *is* in the 
same line as the append command.

Comment 4 Jeremy Katz 2003-04-23 01:58:20 UTC
Looking at the output here, it looks like the command line includes an ip=
that's incorrect.  Could you try adding 'ip=dhcp' to your append line?

Comment 5 Mark Himsley 2003-04-24 14:30:41 UTC
Excuse my stupidity; of cause I should have used the scroll back buffer.
Anyway, I added ip=dhcp to the append line, making the complete line (excuse 
any line wrapping):
append initrd=/rh9.0/initrd.img lang= text devfs=nomount ramdisk_size=8192 nofb 
and that made the Kernel command line (excuse any line wrapping):
initrd=/rh9.0/initrd.img lang= text devfs=nomount ramdisk_size=8192 nofb 
ip=dhcp BOOT_IMAGE=/rh9.0/vmlinuz 
The installer still appears to not configure the network adapter because I 
continue to get "That directory could not be mounted from the serverâ after 
entering values in the 'NFS
setup' dialog and I continue to get the same errors in virtual terminal 4.

Comment 6 Mark Himsley 2003-05-02 11:47:40 UTC
Following an email from Richard Au (below) a solution to this bug has been 

I recently ran into the exact same problem as Mark Himsley doing a 
PXE/Kickstart installation of RedHat 9.0  (Bug 88714).  I took particular note 
of Jeremy Katz's comment about the kernel command line incorrectly including 
an "ip=" entry.  I found out that PXELINUX supports an entry in the 
pxelinux.cfg file: IPAPPEND.  If you set IPAPPEND 1, pxelinux will 
automatically append a ip=<client-ip>:<boot-server-ip>:<gw-ip>:<netmask> entry 
onto the kernel command line.  It seemed to me that this was exactly what was 
happening to my and Mark Himsley's systems.  So, I explicitly specified 
IPAPPEND 0, and added ip=dhcp to the 'append' line.  It worked!! 
Here is my pxelinux.cfg file: 
default linux 
label linux 
    kernel vmlinuz 
    append initrd=initrd.img lang=text ip=dhcp devfs=nomount ramdisk_size=8192 
    ipappend 0 
This bug had been driving me nuts for a several days, and the combined comments 
of Mark and Jeremy allowed me to figure it out much faster than I ever could on 
my own.  Thanks! 
Richard Au 
PANTA Systems
My pxelinux.cfg file did include an  ipappend 1 command and after altering its 
value to 0 I can confirm that the installation of RedHat 9 did work.

I would like to point out that including ipappend 1 in a pxelinux.cfg file had 
no detrimental effect to PXE instals of RedHat 7.x.

Thanks to Richard and Jeremy for their combined help in resolving this issue.

Comment 7 Jeremy Katz 2003-07-28 23:57:38 UTC
Yes, having ipappend set in the pxelinux.cfg file will try to pass the ip to the
installer.  I've added some code to try to keep this from causing problems.

Comment 8 Jeremy Katz 2006-04-24 18:44:25 UTC
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.