FC5. Problem activating eth1 instead of eth0.

Matthew Saltzman mjs at ces.clemson.edu
Wed Jun 28 20:07:56 UTC 2006


On Wed, 28 Jun 2006, Nat Gross wrote:

> On 6/28/06, Matthew Saltzman <mjs at ces.clemson.edu> wrote:
>> On Wed, 28 Jun 2006, Nat Gross wrote:
>> 
>> > On 6/28/06, Matthew Saltzman <mjs at ces.clemson.edu> wrote:
>> > <snip>
>> >> Just curious:  Have you installed the initscripts RPM from 
>> updates-testing
>> >> as I suggested in another thread?
>> > I have not (yet) for three reasons.
>> > 1. I hesitate to use something from 'testing' repos. (Waiting on more
>> > feedback.)
>> 
>> I and a few other people I know have been using it for three months with
>> no apparent ill effects.  The only changelog entry since the original FC5
>> initscripts is:
>> 
>>      * Fri Mar 17 2006 Bill Nottingham <notting at redhat.com> 8.31.2-1
>>      - add udev helper to rename network devices on device creation
>> 
>> Frankly, it is beyond me why this fix continues to languish in
>> updates-testing.
> Let me quote Bill N, on that page:
> " Since this is adding new code to the boot path, it could use
> a good deal of testing; it will be pushed final once I'm
> comfortable that there are no regressions."

Yes, and if you look at the timestamps you'll see that that entry 
post-dates my e-mail.  I pinged the QA contact for that bug and we are now 
seeing movement again.

>
>> > 2. Since for the most part that station's link to the lan/wan is not
>> > working, I need to manually copy the rpm (via cd-rw), then I might run
>> > into a situation where dependant rpm's are required. Without yum on
>> > the wan.....
>> 
>> That's a risk, but I think all the dependencies are now in updates anyway.
>> If not, then the update won't install and you may need one or two more
>> packages.  I'm sure the dependencies don't go very deep and for something
>> like initscripts, it is unlikely that you won't have them already
>> installed.  Particularly considering how small the change is.
>> 
>> > 3. If push comes to shove, the simplest thing might be to physically
>> > remove the second nic.
>> 
>> That should work,
> It DOES!!!
>> but why go to such extremes if there is an alternative?
> after tearing my hair for days with software kernel problems, popping
> the nic (which is a spare) was not that extreme. It took me 30 minutes
> including cleaning some dust outta the box and huffing and puffing to
> get the iron back into place. (Once upon a time, I did hardware.)
> Anyhow, it came right up, no problems or hiccups.
>
> Having said that, you are absolutely right that rhn/fedora should give
> this TOP PRIORITY and get either the fix or a later kernel into the
> stream.
>
> Thank you all;
> nat
>
>
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs




More information about the fedora-list mailing list