Bug 118049

Summary: loader utility in anaconda does not parse some ethtool settings correctly
Product: Red Hat Enterprise Linux 3 Reporter: Neil Horman <nhorman>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jhoskins, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-05-06 21:38:08 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:
Bug Depends On:    
Bug Blocks: 116727    
Attachments:
Description Flags
patch to correct speed parsing none

Description Neil Horman 2004-03-11 14:14:04 UTC 
Description of problem:
when setting ethtool parameters in kickstart on on kernel command line
during install, making the first parameter "speed 10" fails, as loader
does not parse this correctly

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

How reproducible:
always

Steps to Reproduce:
1.insert 3AS-U1 cd into system
2.when boot prompt is presented enter the following line:
ethtool="speed 10 duplex full"
3.continue system boot
4.when prompted select NFS/network install
5.select a network interface to install over
6.select dhcp for ip assignment
7.switch to vt3 and examine logs
  
Actual results:
vt3 dsplays message indicating "Unknown speed 10 duplex half"

Expected results:
speed settings should be successfully driven to network interface

Additional info:
Comment 1 Neil Horman 2004-03-11 14:18:25 UTC 
Created attachment 98459 [details]
patch to correct speed parsing

This problem is being caused by an incorrect value in the strncmp line that
parses speed in the loader utility.  If speed is the first parameter in the
ethtool section of the kernel command line and is set to 10, then this strncmp
will fail becuase it compares 4 characters rather than 2, and the remaining
characters in the string don't match up with the "10" in the binaries string
table.	Interestingly if speed is the last paramter provided, the null
termiators match up and the strncmp fails, allowing for an easy in the field
workaround (just make sure speed is the last parameter).  This patch corrects
the strncmp value and allows speed and duplex to be specified in an arbitrary
order from the boot prompt.
Comment 2 Jeremy Katz 2004-05-06 21:38:08 UTC 
Fixed in CVS for both HEAD and taroon-branch.  I got a little bit
carried away with my cutting and pasting.
Comment 3 Robert Perkins 2004-05-11 20:06:42 UTC 
*** Bug 116618 has been marked as a duplicate of this bug. ***