On 6/28/06, Matthew Saltzman <mjs@xxxxxxxxxxxxxxx> wrote:
On Wed, 28 Jun 2006, Nat Gross wrote:
> On 6/28/06, Matthew Saltzman <mjs@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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."
> 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
