Bug 103124 - LTC4052-'ksdevice=link' can not work on RHEL3 beta1 for i386
LTC4052-'ksdevice=link' can not work on RHEL3 beta1 for i386
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Depends On:
  Show dependency treegraph
Reported: 2003-08-26 15:44 EDT by IBM Bug Proxy
Modified: 2013-07-02 22:28 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:35:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda_eth0.log (6.33 KB, text/plain)
2003-08-28 10:31 EDT, IBM Bug Proxy
no flags Details
anaconda_eth1.log (6.84 KB, text/plain)
2003-08-28 10:31 EDT, IBM Bug Proxy
no flags Details
anaconda_eth0_all.log (6.33 KB, text/plain)
2003-08-28 10:32 EDT, IBM Bug Proxy
no flags Details
anaconda_eth1_all.log (7.04 KB, text/plain)
2003-08-28 10:33 EDT, IBM Bug Proxy
no flags Details

  None (edit)
Description IBM Bug Proxy 2003-08-26 15:44:55 EDT
The following has be reported by IBM LTC:  
We tested the ksdevice=link with RHEL3 on both ppc and i386. It seems that it
works on pSeries but not works on xSeries. The following is our test procedure:

There are two interfaces for the node. 
Case 1) connect eth0 and disconnect eth1 to the network, then run network install
Case 2) disconnect eth0 and connect eth1 to the network, then run network install.

The following are the result:
                Case 1       Case 2
pSeries(ppc)    OK           OK
xSeries(i386)   OK           Failure

for the case2 on xSeries, the /var/log/messages on the install severs is just like:

DHCP request and offer to eth1's MAC address on the node
TFTP server the kernel and ramdisk to the node
<no other messages for the node>    -- There would be a DHCP request and offer
if the "ksdevice=link" worked. At the same time, the kickstart pop up a window
to let you configure the network.

There is another bug related to it :
Glen/Greg - please submit this to Red Hat.  This is a bug against RHEL3 beta1
on x386.  Thanks.I believe that ksdevice=link is a feature of anaconda which,
according to
the bug submitter, works OK on ppc64, but not on x386.
Comment 1 Jeremy Katz 2003-08-26 17:00:56 EDT
This works for me here.  If you then manually select eth1 when prompted does it
work?  What are the contents of /tmp/anaconda.log once you get to the second stage?
Comment 2 Matt Wilson 2003-08-26 20:26:11 EDT
please also provide details on the network cards used - what model was in the
xSeries (IA32)?
Comment 3 IBM Bug Proxy 2003-08-28 10:31:16 EDT
Created attachment 94032 [details]
Comment 4 IBM Bug Proxy 2003-08-28 10:31:57 EDT
Created attachment 94033 [details]
Comment 5 IBM Bug Proxy 2003-08-28 10:32:45 EDT
Created attachment 94034 [details]
Comment 6 IBM Bug Proxy 2003-08-28 10:33:58 EDT
Created attachment 94035 [details]
Comment 7 IBM Bug Proxy 2003-08-28 10:35:19 EDT
------ Additional Comments From jinge@cn.ibm.com  2003-27-08 22:48 -------
The test machine is xSeries netvista. Both two works can work well with
"ks=eth0" or "ks=eth1" options. But when we use "ks=link", eth1 can not work.
The following are detailed test process:

Case 1) connect eth0 and disconnect eth1 to the network, then run network install
It is ok.

Please see attachment anaconda_eth0.log

Case 2) disconnect eth0 and connect eth1 to the network, then run network install.
It does not work. A window prompt for choosing network interface: eth0 or eth1.
If I select eth1 manually, it works.

Please see attachment anaconda_eth1.log

Case 3) eth0 and eth1 all connect to network, but dhcp configure only one: eth0
or eth1, then run network install
dhcp configure eth0: it works

Please see attachment anaconda_eth0_all.log

dhcp configure eth1: it does not work. A window prompt to configure
networkinterface.I configure network to static IP manually, then it works.

Please see attachment anaconda_eth1_all.log 
Comment 8 Jeremy Katz 2003-08-28 10:46:26 EDT
One of the two nics (I'm guessing the one using 8139too, but icbw) doesn't
support telling about link status as we try for five seconds and never get anything.
Comment 9 IBM Bug Proxy 2003-08-28 23:42:41 EDT
------ Additional Comments From jinge@cn.ibm.com  2003-28-08 22:57 -------
We replaced 8159 with 3c509. The case 1 and case 2 passed. But case 3 still
fail. It seems that anaconda will not try the second linked nic even if it don't
get IP for the first linked nic. Is it the limitation of anaconda? If so, do you
have a plan to remove the limitation?  It will be helpful if anaconda can try to
bring up all linked nics? 
Comment 10 IBM Bug Proxy 2003-09-08 08:55:45 EDT
------ Additional Comments From jinge@cn.ibm.com  2003-08-09 03:59 -------
waiting for reply... 
Comment 11 IBM Bug Proxy 2003-09-09 10:45:55 EDT
------ Additional Comments From jinge@cn.ibm.com  2003-08-09 22:25 -------
We tried it on RHEL3 beta2. 
Comment 12 Greg Kelleher 2003-09-10 12:36:42 EDT
Issue still exists on Beta 2
Comment 13 Jeremy Katz 2003-10-13 19:42:34 EDT
Does this work with the RC?
Comment 14 IBM Bug Proxy 2003-10-14 10:31:16 EDT
------ Additional Comments From jinge@cn.ibm.com  2003-14-10 04:01 -------
I have no chance to verify the defect in RC. I'll do it this week. 
Comment 15 mark wisner 2003-11-25 02:00:26 EST
------ Additional Comments From khoa@us.ibm.com  2003-25-11 01:59 -------
Ge - please verify if this bug still exists in RHEL3 GA.  Thanks. 
Comment 16 mark wisner 2003-11-26 06:01:05 EST
------ Additional Comments From jinge@cn.ibm.com  2003-25-11 21:47 -------
The problem still exist in RHEL3 GA. 
Comment 18 mark wisner 2004-11-19 14:21:56 EST
Please try this in U4.
Comment 19 Jeff Garzik 2005-02-18 02:33:46 EST
I think this one was auto-fixed in an update.

Can anyone confirm?
Comment 20 IBM Bug Proxy 2005-02-25 17:07:07 EST

           What    |Removed                     |Added
             Status|NEEDINFO                    |OPEN

------- Additional Comments From khoa@us.ibm.com  2005-02-25 17:06 EST -------
Ge - please verify (or ask someone to verify) if this bug still happens
on RHEL4 U4 ?  Red Hat believes that this has been fixed.  Thanks. 
Comment 21 nathan r. hruby 2005-03-22 09:13:54 EST
PING: ksdevice=link on a HP Dl360 G4 in rhel-3-u4-as does not work when link
device is eth1..  Manual selection for eth1 when prompted does work.

Boot line is:
linux console=ttyS0 ks=http://some_satellite/kickstart/ks/label/some_label
ksdevice=link ip=some_ip netmask=some_netmask dns=some_dns

Comment 22 RHEL Product and Program Management 2007-10-19 15:35:05 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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