Bug 28061
Summary: | During Kickstart installation Anaconda fails to default to eth0 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Christopher Stanton <christopher_stanton> |
Component: | anaconda | Assignee: | Michael Fulbright <msf> |
Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | michael_e_brown |
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: | 2001-02-22 17:16:18 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: |
We (Red Hat) should really try to resolve this before next release. 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. --------------------------- Maybe, ks=nfs:myserver:/tftpboot/ks/myksfile|eth:eth0 or ks=nfs:myserver:/tftpboot/ks/myksfile ks=eth:eth0 Oops. In the comment above, DHCP should be pxelinux. Sorry, Christopher 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. Was the fact that it is supposed to defaut to eth0 but does not resolved as not a bug? why would it default to eth0? Our installer team-lead thinks we should really fix this before next release. Have tested the ksdevice=ethx fix mentioned above. The only thing left to do is to change the documentation. The documentation at this url: http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/s1-kickstart2-startinginstall.html Does not mention the 'ksdevice=' parameter. In fact this page: http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/s1-kickstart2-commands.html 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. |
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) 3. Actual Results: Anaconda prompts the user for input at the start of the installation Expected Results: Anaconda uses eth0 by default