Bug 118049 - loader utility in anaconda does not parse some ethtool settings correctly
Summary: loader utility in anaconda does not parse some ethtool settings correctly
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard:
: 116618 (view as bug list)
Depends On:
Blocks: 116727
TreeView+ depends on / blocked
 
Reported: 2004-03-11 14:14 UTC by Neil Horman
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-05-06 21:38:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch to correct speed parsing (760 bytes, patch)
2004-03-11 14:18 UTC, Neil Horman
no flags Details | Diff

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. ***


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