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 users
mailing list