SCIENTIFIC-LINUX-USERS Archives

February 2008

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Miles O'Neal <[log in to unmask]>
Reply To:
Miles O'Neal <[log in to unmask]>
Date:
Tue, 19 Feb 2008 08:47:44 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
Pierre Frenkiel said...
|
|On Mon, 18 Feb 2008, Beyerle Urs wrote:
|
|> try to bind eth0 and eth1 to the MAC address of the devices.
|
|   Thanks. That's a better workaround than mine, but is still a workaround.
|   I would like to understand why this is neccessary since SL5.0, and
|   only for this machine...

It's not only since SL5 or only for that
machine, although it may well seem so.

In fact, it appears to be random with low
probability, but any given system seems
more or less likely with a given kernel
to exhibit this behavior.

I have no idea why, but we've seen it since
RH7.1 or RH8, I forget which[1].  A system
that worked fine on RH8 blew on on SL3 and
vice versa.  One that acted wonky on SL3
works fine on SL4 and vice versa.  We won't
move to SL5 any time soon because we're
driven by third party tool support, but it
won't surprise me if it still occurs.

Binding the ethX port to the MAC address
has generally worked for us and seems to be
the standard way to address this.

In my book this has always been broken
behavior.  I have no idea why it occurs,
and it's certainly annoying.

-Miles

[1] We only had one dual NIC Linux system
    before that, and it simply never gets
    rebooted except after prolonged power
    failures.

ATOM RSS1 RSS2