Bug 28061 - During Kickstart installation Anaconda fails to default to eth0
During Kickstart installation Anaconda fails to default to eth0
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-02-16 18:32 EST by Christopher Stanton
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-22 12:16:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Christopher Stanton 2001-02-16 18:32:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

1) The docs state that during a Kickstart installation over 
NFS Anaconda will default to eth0.

From RedHat 7.0: The Official Red Hat Linux Reference Guide: page 512

>If the installation does require networking, Anaconda assumes that
>the install should be done over eth0 via a dynamic IP address 
>(BOOTP/DHCP), and configures the final, installed system to
>dynamically determine its IP address.

On a machine with multiple network devices, Anaconda stops and
prompts the user for the eth to use during installation.

2) There needs to be a way to configure which eth will be
used rather than it defaulting to eth0

Reproducible: Always
Steps to Reproduce:
1.set up a Kickstart server for Kickstarting machines usign DHCP and NFS
2.Boot the client node (which has multiple eth interfaces)

Actual Results:  Anaconda prompts the user for input at the start of the 

Expected Results:  Anaconda uses eth0 by default
Comment 1 Glen Foster 2001-02-21 13:22:48 EST
We (Red Hat) should really try to resolve this before next release.
Comment 2 Christopher Stanton 2001-02-21 13:37:29 EST
Is there any way to have it user settable as well? 
Passed in the same way the nfs parm is passed by DHCP as a kernel parm that is 
ignored by the kernel and passed to Anaconda?
ks=nfs: <server:>/ <path>
The installation program will look for the kickstart file on the NFS server
<server>, as file <path>. The installation program will use DHCP to con-figure
the Ethernet card.

ks=nfs:myserver:/tftpboot/ks/myksfile ks=eth:eth0
Comment 3 Christopher Stanton 2001-02-22 12:16:14 EST
Oops. In the comment above, DHCP should be pxelinux.

Comment 4 Matt Wilson 2001-02-22 14:26:30 EST
two ways (since Red Hat Linux 7)

use "ksdevice=eth0" as an extra argument when booting the image (this is so you
can boot with "ks=nfs:/path ksdevice=eth0" for dhcp nfs installs.

use "network device=eth0 ..."is ks.cfg if it is located on local media.
Comment 5 Christopher Stanton 2001-02-22 16:01:33 EST
Was the fact that it is supposed to defaut to eth0 but does not resolved as not 
a bug?

Comment 6 Matt Wilson 2001-02-26 23:55:40 EST
why would it default to eth0?
Comment 7 Glen Foster 2001-03-02 13:06:21 EST
Our installer team-lead thinks we should really fix this before next release.
Comment 8 Michael E Brown 2001-03-02 14:44:37 EST
Have tested the ksdevice=ethx fix mentioned above. The only thing left to do is
to change the documentation. The documentation at this url: 
Does not mention the 'ksdevice=' parameter.

In fact this page:

has this information, which is the original source of this bugreport:

network (optional)
    Configures network information for the system. If it is not given, and the
kickstart installation does not require networking (in other words, it's not
installed over NFS), networking is not configured for the system. If the
installation does require networking, Anaconda assumes that the install should
be done over eth0 via a dynamic IP address (BOOTP/DHCP), and configures the
final, installed system to dynamically determine its IP address. The network
command configures the networking information for the installation for network
kickstarts as well as for the final, installed system.

This is the documentation that should be changed, and it should mention the
'ksdevice=' parameter.

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