FC5. Problem activating eth1 instead of eth0.

[Nat Gross]

Hi.
On a Dell 4400, 1.6ghz pci based system which has two ethernet cards
installed, running 32 bit FC5 latest kernel, 2.6.17-1.2139_FC5,  I
have the following emergency.
(This machine was upgraded from FC4 to FC5 yesterday and was rebooted
yesterday, a-ok, before the current problem struck.)
My config did NOT use eth1 (was deactivated), only eth0, and was the
only nic physically connected to the router. Tonight after a reboot,
this cpu ceased seeing the lan, and others coudn't ping it as well.
Fiddling around in back of the machine I noticed that the eth0 card
was loose in the socket. I brought down the system, re-inserted the
card, but still didn't work. So, I assumed that maybe the card burnt
out since it was loose. No sweat, I thought, that is why I have the
spare nic. I ran the networking applet,
deactivated eth0, activated (and plugged in) eth1, tried service
network restart, it showed eth1[ok] but.... no bytes, 0, nadda. Same
after a reboot.
I then copied /etc/sysconfig/networking/devices/ifcfg-eth0 over to
ifcfg-eth1, UNPLUGGED eth0 from the router, set the ip address in eth1
to the same as eth0 had, rebooted but still -NADDA-.
The queer thing is that it insists the both eth0 and eth1 are active,
regardless as to how I set it via the applet. (It reverts to active.)
Fwiw, I do NOT have the NetworkServices daemon active.
Hopefully I missed doing something elementary.
Your help is mostly appreciated.
-nat

[Chong Yu Meng]

On Mon, 2006-06-26 at 23:46 -0400, Nat Gross wrote:
>  Hi.
>  On a Dell 4400, 1.6ghz pci based system which has two ethernet cards
>  installed, running 32 bit FC5 latest kernel, 2.6.17-1.2139_FC5,  I
>  have the following emergency.
>  (This machine was upgraded from FC4 to FC5 yesterday and was rebooted
>  yesterday, a-ok, before the current problem struck.)
>  My config did NOT use eth1 (was deactivated), only eth0, and was the
>  only nic physically connected to the router. Tonight after a reboot,
>  this cpu ceased seeing the lan, and others coudn't ping it as well.
>  Fiddling around in back of the machine I noticed that the eth0 card
>  was loose in the socket. I brought down the system, re-inserted the
>  card, but still didn't work. So, I assumed that maybe the card burnt
>  out since it was loose. No sweat, I thought, that is why I have the
>  spare nic. I ran the networking applet,
>  deactivated eth0, activated (and plugged in) eth1, tried service
>  network restart, it showed eth1[ok] but.... no bytes, 0, nadda. Same
>  after a reboot.
>  I then copied /etc/sysconfig/networking/devices/ifcfg-eth0 over to
>  ifcfg-eth1, UNPLUGGED eth0 from the router, set the ip address in eth1
>  to the same as eth0 had, rebooted but still -NADDA-.
>  The queer thing is that it insists the both eth0 and eth1 are active,
>  regardless as to how I set it via the applet. (It reverts to active.)
>  Fwiw, I do NOT have the NetworkServices daemon active.
>  Hopefully I missed doing something elementary.
>  Your help is mostly appreciated.
>  -nat
>   
Hi Nat,

Is it possible for you to fallback to the previous kernel version. Seems
like a lot of people are having problems with NICs switching places, and
the one thing in common seems to be the latest kernel version.

-- 
Pascal Chong 
email:  chongym(a)cymulacrum.net 
web:    http://cymulacrum.net
pgp:    http://cymulacrum.net/pgp/cymulacrum.asc

"La science ne connaît pas de frontière parce que la connaissance
appartient à l’humanité. et que c’est la flamme qui illumine le monde."

-- Louis Pasteur

[Nat Gross]

On 6/27/06, Chong Yu Meng <chongym(a)cymulacrum.net&gt; wrote:
>  Hi Nat,
>
>  Is it possible for you to fallback to the previous kernel version. Seems
>  like a lot of people are having problems with NICs switching places, and
>  the one thing in common seems to be the latest kernel version.
>  
I tried, but it didn't help. (I started having gui problems with the
previous kernel version -seems like some newer pkgs  depend on it- so
I quickly switched back to the latest kernel.) It behaved the same as
with the latest kernel.
Please note that I did have a working system with the latest kernel.
Thanks;
-nat

[Nat Gross]

On 6/26/06, Nat Gross <nat101l(a)gmail.com&gt; wrote:
>  Hi.
>  On a Dell 4400, 1.6ghz pci based system which has two ethernet cards
>  installed, running 32 bit FC5 latest kernel, 2.6.17-1.2139_FC5,  I
>  have the following emergency.
>  (This machine was upgraded from FC4 to FC5 yesterday and was rebooted
>  yesterday, a-ok, before the current problem struck.)
>  My config did NOT use eth1 (was deactivated), only eth0, and was the
>  only nic physically connected to the router. Tonight after a reboot,
>  this cpu ceased seeing the lan, and others coudn't ping it as well.
>  Fiddling around in back of the machine I noticed that the eth0 card
>  was loose in the socket. I brought down the system, re-inserted the
>  card, but still didn't work. So, I assumed that maybe the card burnt
>  out since it was loose. No sweat, I thought, that is why I have the
>  spare nic. I ran the networking applet,
>  deactivated eth0, activated (and plugged in) eth1, tried service
>  network restart, it showed eth1[ok] but.... no bytes, 0, nadda. Same
>  after a reboot.
>  I then copied /etc/sysconfig/networking/devices/ifcfg-eth0 over to
>  ifcfg-eth1, UNPLUGGED eth0 from the router, set the ip address in eth1
>  to the same as eth0 had, rebooted but still -NADDA-.
>  The queer thing is that it insists the both eth0 and eth1 are active,
>  regardless as to how I set it via the applet. (It reverts to active.)
>  Fwiw, I do NOT have the NetworkServices daemon active.
>  Hopefully I missed doing something elementary.
>  Your help is mostly appreciated.
>  -nat
>  
SOLVED!! I suddenly remembered that a long time ago, when I had
network problems, I SHUT DOWN the ROUTERS, after changing nics (or
whatever it was then). So, this is what I did now, and voila!
Thank you all, and hope this helps.
-nat
ps. um Forgot to methion I also turned the routers back on<g>.

[Les Mikesell]

On Tue, 2006-06-27 at 13:59 -0400, Nat Gross wrote:
>  >
>  SOLVED!! I suddenly remembered that a long time ago, when I had
>  network problems, I SHUT DOWN the ROUTERS, after changing nics (or
>  whatever it was then). So, this is what I did now, and voila!
>  Thank you all, and hope this helps.
>  -nat
>  ps. um Forgot to methion I also turned the routers back on<g>. 
Routers tend to cache the arp associations (tcp/mac) for a
much longer time than other equipment - perhaps 20 minutes.
With Cisco's you can log into them and use the command
'clear arp' instead of restarting - other routers probably
have similar commands.

-- 
  Les Mikesell
   lesmikesell(a)gmail.com

[Nat Gross]

On 6/27/06, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  On Tue, 2006-06-27 at 13:59 -0400, Nat Gross wrote:
>  > >
>  > SOLVED!! I suddenly remembered that a long time ago, when I had
>  > network problems, I SHUT DOWN the ROUTERS, after changing nics (or
>  > whatever it was then). So, this is what I did now, and voila!
>  > Thank you all, and hope this helps.
>  > -nat
>  > ps. um Forgot to methion I also turned the routers back on<g>.
>
>  Routers tend to cache the arp associations (tcp/mac) for a
>  much longer time than other equipment - perhaps 20 minutes.
>  With Cisco's you can log into them and use the command
>  'clear arp' instead of restarting - other routers probably
>  have similar commands.
>  
****** ALAS! IT STRUCK AGAIN! IT *IS* the KERNEL! ********************
Upon a subsequent reboot (why did I reboot!!), I went thru the
rigmarole all over again. In the past 8 hours of more tinkering, I
have ascertained that my original eth0 card works as well, if I shut
off the system and reboot the old kernel. But the old kernel gives me
some ati related problems (it's the first kernel shipped with FC5).
Anyhow, on another machine, I also have FC5 and this latest kernel,
but only one nic physically installed, and have NO problems.
So, the question is, can I totally HIDE the eth1 nic from the os,
as-if it didn't exist?
Thanks;
nat

[Matthew Saltzman]

On Tue, 27 Jun 2006, Nat Gross wrote:

>  On 6/27/06, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
> > On Tue, 2006-06-27 at 13:59 -0400, Nat Gross wrote:
> > > >
> > > SOLVED!! I suddenly remembered that a long time ago, when I had
> > > network problems, I SHUT DOWN the ROUTERS, after changing nics (or
> > > whatever it was then). So, this is what I did now, and voila!
> > > Thank you all, and hope this helps.
> > > -nat
> > > ps. um Forgot to methion I also turned the routers back on<g>.
> > 
> > Routers tend to cache the arp associations (tcp/mac) for a
> > much longer time than other equipment - perhaps 20 minutes.
> > With Cisco's you can log into them and use the command
> > 'clear arp' instead of restarting - other routers probably
> > have similar commands.
> > 
>  ****** ALAS! IT STRUCK AGAIN! IT *IS* the KERNEL! ********************
>  Upon a subsequent reboot (why did I reboot!!), I went thru the
>  rigmarole all over again. In the past 8 hours of more tinkering, I
>  have ascertained that my original eth0 card works as well, if I shut
>  off the system and reboot the old kernel. But the old kernel gives me
>  some ati related problems (it's the first kernel shipped with FC5).
>  Anyhow, on another machine, I also have FC5 and this latest kernel,
>  but only one nic physically installed, and have NO problems.
>  So, the question is, can I totally HIDE the eth1 nic from the os,
>  as-if it didn't exist?
>  Thanks;
>  nat 
Just curious:  Have you installed the initscripts RPM from updates-testing 
as I suggested in another thread?

-- 
 		Matthew Saltzman

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

[Nat Gross]

On 6/28/06, Matthew Saltzman <mjs(a)ces.clemson.edu&gt; 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.)
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.....
3. If push comes to shove, the simplest thing might be to physically
remove the second nic.
Am just wondering, would bonding the two nics into one virtual ip
address (both plugged into the same router on the same lan segment)
solve the problem?

nat

[Matthew Saltzman]

On Wed, 28 Jun 2006, Nat Gross wrote:

>  On 6/28/06, Matthew Saltzman <mjs(a)ces.clemson.edu&gt; 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(a)redhat.com&gt; 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.

>  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, but why go to such extremes if there is an alternative?

>  Am just wondering, would bonding the two nics into one virtual ip
>  address (both plugged into the same router on the same lan segment)
>  solve the problem? 
I doubt it.  I think the confusion is over which NIC Linux thinks is 
associated with which device.

>  nat
>
>
>  
-- 
 		Matthew Saltzman

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

[Nat Gross]

On 6/28/06, Matthew Saltzman <mjs(a)ces.clemson.edu&gt; wrote:
>  On Wed, 28 Jun 2006, Nat Gross wrote:
>
>  > On 6/28/06, Matthew Saltzman <mjs(a)ces.clemson.edu&gt; 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(a)redhat.com&gt; 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

[Matthew Saltzman]

On Wed, 28 Jun 2006, Nat Gross wrote:

>  On 6/28/06, Matthew Saltzman <mjs(a)ces.clemson.edu&gt; wrote:
> > On Wed, 28 Jun 2006, Nat Gross wrote:
> > 
> > > On 6/28/06, Matthew Saltzman <mjs(a)ces.clemson.edu&gt; 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(a)redhat.com&gt; 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