Bug 60244 - loader should scan all ethX devices when doing network installs
loader should scan all ethX devices when doing network installs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-22 13:01 EST by Matt Domsch
Modified: 2007-04-18 12:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-03 12:26:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2002-02-22 13:01:19 EST
Description of Problem:
It's very difficult to match ethX<->physical ethernet jack on systems with more 
than one ethernet jack.  Consider the case where we install seven dual-port 
NICs plus have two embedded NICs.  The guy in the factory won't always know 
which jack matches eth0 which the installer needs to know.

Anaconda loader should, during network installs (particularly kickstart 
installs), try to obtain DHCP addresses and contact the network server, for all 
ethX devices found, before falling back to CD-ROM installs as it currently 
does.  Perhaps keep the DHCP timeout short - if a cable isn't attached to that 
port, you don't want a 2+ minute timeout, times the number of NIC ports, to 
figure that out.

Ideally this would be implemented for both Pensacola and Hampton.

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


How Reproducible:


Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:
Comment 1 Michael Fulbright 2002-02-25 14:20:28 EST
Jeremy do you think this is doable on a Hampton timescale?

It certainly is not doable for Pensacola.
Comment 2 Jeremy Katz 2002-03-06 12:00:45 EST
Possibly for Hampton, largely dependent on what else breaks and requires fixing.
 Also, when it is done, it will probably require a special boot option to enable
as for the general case, it is not the desired behavior due to the much longer
period of time it will cause if you have to cycle through and timeout on
multiple interfaces.
Comment 3 Matt Domsch 2002-03-06 12:05:37 EST
boot option and/or kickstart directive would be fine.  boot option gives more 
flexibility as to where we put ks.cfg then.
Comment 4 Larry Troan 2003-01-12 12:56:28 EST
THIS BUG IS 10 MONTHS OLD (pre 7.3?). IS THIS STILL ACTIVE? If not, we should
close this bug. NOTE: Not in Feature Tracker. 
Comment 5 Larry Troan 2003-01-29 15:40:58 EST
OPENED FEATURE TRACKER #800 for this Bugzilla.
Comment 6 Michael Fulbright 2003-06-30 16:00:31 EDT
Jeremy was thinking of implementing ksdevice=any.
Comment 7 Jeremy Katz 2003-06-30 16:07:53 EDT
Added ksdevice=link which will use the first device with an apparently active link.
Comment 8 Matt Domsch 2003-09-03 12:26:34 EDT
Thanks much, will test and open bugs if necessary.  Closing feature request.

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