SCIENTIFIC-LINUX-USERS Archives

July 2014

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:
Reply To:
Date:
Tue, 29 Jul 2014 10:46:26 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
On Tue, Jul 29, 2014 at 5:57 AM, SCHAER Frederic <[log in to unmask]> wrote:
>> De : De la part de Tom H
>> Envoyé : lundi 28 juillet 2014 23:35
>> On Mon, Jul 28, 2014 at 5:35 AM, SCHAER Frederic <[log in to unmask]> wrote:
>>>
>>> From time to time, we get reboot issues with some machines, and each time it
>>> looks like there are duplicated persistent rules for the Ethernet devices :
>>>
>>> cat /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> # PCI device 0x8086:0x1521 (igb) (custom name provided by external tool)
>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>> ATTR{address}=="84:8f:69:fb:c1:2a", ATTR{type}=="1", KERNEL=="eth*",
>>> NAME="em1"
>>>
>>> # PCI device 0x8086:0x1521 (igb) (custom name provided by external tool)
>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>> ATTR{address}=="84:8f:69:fb:c1:2b", ATTR{type}=="1", KERNEL=="eth*",
>>> NAME="em2"
>>>
>>> # PCI device 0x8086:0x1521 (igb) (custom name provided by external tool)
>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>> ATTR{address}=="84:8f:69:fb:c1:2a", ATTR{type}=="1", KERNEL=="eth*",
>>> NAME="eth0"
>>>
>>> # PCI device 0x8086:0x1521 (igb) (custom name provided by external tool)
>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>> ATTR{address}=="84:8f:69:fb:c1:2b", ATTR{type}=="1", KERNEL=="eth*",
>>> NAME="eth1"
>>>
>>> The second set of rules seem to overwrite the first one, and then we get
>>> issues with our network config.
>>>
>>> This does not happen on all nodes, just apparently to some random ones,
>>> sometimes.
>>>
>>> I’m wondering if some of you might have faced and solved that erratic thing
>>> already ?
>>>
>>> We want to keep the emX scheme for nodes which support it…
>>
>> The emX names come from biosdevname (part of a base install):
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/appe-
>> Consistent_Network_Device_Naming.html
>>
>> You should be able to delete the last two rules, the ethX rules, for
>> your interfaces to use the emX names, unless you're using
>> "biosdevname=0" on the kernel cmdline.
>
> Thanks for your reply.
>
> That's actually what I do to recover a happy system, but I'd like to prevent this from hapenning.
> I don't want to force ethX when nodes support emX, but when I use emX, I don't want neither the system to suddenly tell me emX became ethX, which is what happens.
>
> What I'm wondering is  why do I suddenly have both the emX and ethX devices in udev, despite the fact the node has lived for days with emX only, rebooted correctly without changing anything...?
>
> Firmware bug ? (I know emX scheme depends on firmwares and DMI information...)

The only time that I've seen "write_net_rules" write a new rule in
70-persistent-net.rules is when there's a error in the existing rule,
usually an incorrect mac address.

But this isn't the case here so either you've hit a bug or biosdevname
was disabled on your system either by using "biosdevname=0" on the
kernel cmdline or by uninstalling biosdevname.

To ensure that this doesn't happen:

mv /etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/90-netX-persistent-net.rules
ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules

ATOM RSS1 RSS2