LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 09-15-2011, 03:29 PM   #1
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
overriding /etc/udev/rules.d/70-persistent-net.rules


I've tried replacing /etc/udev/rules.d/70-persistent-net.rules with my own rules that I believe should work for my situations. However, udev is replacing that file at times. It does not always do so, but sometimes it does.

I tried renaming my rules to another file name, and I remove the /etc/udev/rules.d/70-persistent-net.rules file. Sometimes nothing happens here and all works well. But sometimes udev generates /etc/udev/rules.d/70-persistent-net.rules (it's always the same wrong way each time). When both rules exist, the interfaces have the wrong names.

I want to do one of:

1. Get udev to stop generating its rules (that are wrong).
2. Get udev to generate correct rules.
3. Make my rules always override the generated rules.

My rules match interfaces based on bus device address, not ethernet MAC address. Here's a little script I wrote to generate what I believe are better rules than udev generates:
Code:
#!/bin/bash

# Generate udev rules to order interfaces in the same order as their bus addresses.

if ! test -d /sys/devices ; then
    echo "${0}: ERROR: /sys appears to not be mounted" 1>&2
    exit 1
fi

scansys() {
    find /sys/devices -type d -wholename '/sys/devices/pci*/net' -print
}

extract() {
    awk -F/ '{printf "%s eth%u\n",$(NF-1),NR-1;}'
}

generate() {
    echo '# these rules are for persistence based on bus device address'
    awk '{printf "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\", KERNELS==\"%s\", KERNEL==\"eth*\", NAME=\"%s\"\n",$1,$2;}'
}

scansys | extract | sort | generate
This just outputs the generated rules to stdout, if you want to try it and see what it does.
 
Old 09-15-2011, 05:33 PM   #2
ccolumbu
Member
 
Registered: Oct 2009
Posts: 37

Rep: Reputation: 4
You want ifrename (redhat OS based answer)

You want to install the wireless-tools package via yum (which provides ifrename) if you don't already have it, as well as ethtool for testing.
Code:
yum install wireless-tools ethtool
Then create an /etc/init.d script for ifrename and an /etc/iftab config file (see below).

Once you have the script and the iftab you can test it, if you are at the console. Do not try this remotely!
First blink the nic so you know it is not what you want (it should make the link like blink at a steady rate. It helps if the NIC is not plugged in):
Code:
ethtool -p eth0
Now run this:
Code:
/etc/init.d/network stop
/etc/init.d/ifrename restart
/etc/init.d/network start
Then test again, and the cards should have changed assignments:
Code:
ethtool -p eth0
Once that works simply add ifrename to your startup:
Code:
chkconfig ifrename on
/etc/iftab example:
Code:
eth0 mac <mac of the NIC you want as eth0 like: ##:##:##:##:##:##>
eth1 mac <mac of the NIC you want as eth1 like: ##:##:##:##:##:##>
. . . 
ethN mac <mac of the NIC you want as ethN like: ##:##:##:##:##:##>
Here is an ifrename init.d script:
Code:
#!/bin/sh
#
# chkconfig: 2345 09 60
# description: /sbin/ifrename
# processname: ifrename
#

# Source function library.
. /etc/rc.d/init.d/functions

[ -x /sbin/ifrename ] || exit 0

# Define where ifrename is installed. 
DAEMON="/sbin/ifrename"
OPTIONS="-t"

RETVAL=0

start() {
        if status $DAEMON > /dev/null; then
                echo -n $"$DAEMON: already running "
                failure
                echo
                return 1
        fi

        # Start daemons.
        echo -n $"Starting ifrename: "
        daemon $DAEMON $OPTIONS
        RETVAL=$?
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/ifrename
        echo
        return $RETVAL
}

stop() {
        # Stop daemons.
        echo -n $"Shutting down ifrename: "
        echo OK
        return 0
}

restart() {
        stop
        sleep 1
        start
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  status)
        status ifrename
        ;;
  *)
        echo "Usage: /etc/init.d/ifrename {start|stop|restart|status}"
        exit 1
esac

exit $?
 
Old 09-16-2011, 02:29 PM   #3
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
The example given shows only doing it by MAC address. How can I do this with your example, but by BUS address?

Note that I do NOT want a specific address to interface name mapping. Instead, I want the interfaces sorted by BUS address to be named sequentially (e.g. eth0 for the lowest BUS address, eth1 for the next lowest BUS address, and so on).
 
Old 09-16-2011, 02:53 PM   #4
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Would renaming your rule set to 99-persistent-net.rules help? Your rule set would run after udev checks/resets 70-persistent-net.rules.
 
Old 09-16-2011, 11:21 PM   #5
ccolumbu
Member
 
Registered: Oct 2009
Posts: 37

Rep: Reputation: 4
Ifrename has a bunch of options, read this for non-mac specific solutions:
http://linux.die.net/man/5/iftab
 
Old 09-17-2011, 08:15 PM   #6
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by ccolumbu View Post
Ifrename has a bunch of options, read this for non-mac specific solutions:
http://linux.die.net/man/5/iftab
Sure, ifrename could do the renaming once. But it doesn't have an automatic means to juggle conflicting names. That is, if you need to rename eth1 to eth0, and eth0 to eth1, there is a conflict. I've tried that with ifrename and it didn't change anything. It only reported the first conflict. Somehow, udev, if it needs to switch, automatically handles it. I presume it renames one of the interfaces first to a temporary name, then renames as needed to get the interfaces back in line.

Also, if udev is running, ifrename and udev can interfere with each other. And I do need to run udev. I just need to find out how to make udev not mangle the files I make.
 
Old 09-18-2011, 12:25 AM   #7
ccolumbu
Member
 
Registered: Oct 2009
Posts: 37

Rep: Reputation: 4
if you give ifrename the -t flag it can handle conflicts, I run both right now on multiple servers. and regularly rename eth0 -> eth1, then eth1 -> eth0.
Read the page I set you it tells you how to do everything you asked.
 
Old 09-19-2011, 11:14 AM   #8
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by ccolumbu View Post
if you give ifrename the -t flag it can handle conflicts, I run both right now on multiple servers. and regularly rename eth0 -> eth1, then eth1 -> eth0.
Read the page I set you it tells you how to do everything you asked.
There is still interference from udev. It changes things around afterwards. So the only solution I see is to do it through udev. When I give udev a ruleset to do this, but named different than the default ruleset it generates, it doesn't seem to use this ruleset at all, but it does not delete it. When I give that ruleset the same name as what udev would generate with MAC addresses, it USUALLY does not replace it, but SOMETIMES it does. I have not worked out the situation where it does replace it. But I suspect it might be a situation where the kernel named the interfaces differently because of the random probe responses coming in differently.
 
Old 09-19-2011, 11:15 PM   #9
ccolumbu
Member
 
Registered: Oct 2009
Posts: 37

Rep: Reputation: 4
Is it reporting it 1 way in ifconfig, but correctly when yo use ethtool -p ethX?
This is a problem I have reported on the CentOS bug tracker.

Test to see if ethX is the card you expect by running ethtool -p ethX and looking to see which one blinks.

I don't know anything about udev, so I can't be of additional help.
Sorry.
 
Old 09-20-2011, 10:32 AM   #10
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by ccolumbu View Post
Is it reporting it 1 way in ifconfig, but correctly when yo use ethtool -p ethX?
This is a problem I have reported on the CentOS bug tracker.

Test to see if ethX is the card you expect by running ethtool -p ethX and looking to see which one blinks.

I don't know anything about udev, so I can't be of additional help.
Sorry.
I have already tested that the cards go where expected when individually bringing them up and down. The only issue is that udev re-arranges the interface names.

Before I ever did anything, it would lock in MAC addresses to names, and store a rules file to do that. But binding name to MAC is wrong for what I'm doing for two reasons. We do move systems that reside on hard drives from one machine to another at times. We also change NIC cards at times. That's when udev fouls up the network arrangement. While in the local data room, we could get on the console and fix the udev rules, this is not so easy for remote machines where staff are less technically inclined. At first, I corrected this by putting in a set of rules for all ethernets that precluded any renaming by udev. But this disables the ability to correct for kernel probe order errors. So it merely improved the situation, but did not correct it.

My latest change to bind interface naming order to bus address order appears to add more improvement. Most of the time udev accepts the rules my script generates and the interface names come up in the expected order. But rarely, maybe about 1 in 80 times booting, udev ignores the rules my script generates, and substitutes them with its own, just as if the rules were not there. I verified the rules were there by running my script, which also lists the new file it makes, right before udev starts, in the script that starts udev itself. But I see no log messages about udev deciding the rules were to be replaced. It just silently replaces them in these rare cases.

FYI, I was running a test by rebooting a test machine every 72 seconds. A script that was doing the reboot via ssh would do this about 80 to 100 times just fine, then suddenly it cannot connect because the target machine's . Checking the console of the test target showed that the kernel did have the interfaces out of order, my script did run and generate rules, udev did not follow those rules, and replaced the rules with its own, being the same as if there had been no rules at all. I cannot rule out a system error in the filesystem that caused the rules to not be present for udev. I did add a sync command in the init script right before it lists the generated rules file. I'm considering running udev entirely under strace to keep a log of all system calls it does. I hope strace doesn't break it.
 
Old 05-23-2012, 03:57 PM   #11
Magnusg
LQ Newbie
 
Registered: Sep 2009
Posts: 3

Rep: Reputation: 0
Skaperen, thanks for the script. It was really helpful to me.

Keep in mind, /etc/udev/rules.d/70-persistent-net.rules on RHEL6 and others is updated by /lib/udev/write_net_rules.

I used your script to replace write_net_rules, worked like a charm and make sure that 70-persistent-net.rules becomes more stable.
Keep in mind, /lib/udev/write_net_rules is owned by the udev RPM on RHEL6, so updating it would require you to reapply your changed write_net_rules.
I did this by putting your script in a RHN Satellite configuration channel.

This is described more in detail here: http://blog.hacka.net/#post64

Again, thanks Skaperen.
 
Old 03-06-2014, 09:24 PM   #12
z_haseeb
Member
 
Registered: Jun 2008
Posts: 34

Rep: Reputation: 0
@ Skaperen

CURRENTLY i AM FACING THE SAME PROBLEM. mAY THIS RESOLVE YOUR PROBLEM.
1.) create a copy of , /etc/udev/rules.d/70-persistent-net.rules to some where.
2.) run rm -rf , /etc/udev/rules.d/70-persistent-net.rules under rc.local
3.) cp /WHERE-YOU-COPIED-THE-FILE /etc/udev/rules.d/70-persistent-net.rules


(correct me if I am wrong)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reset/remove udev persistent-net-rules cccc Debian 3 06-29-2012 11:46 AM
correcting udev network persistent-net rules Skaperen Linux - Networking 2 09-19-2011 04:11 PM
Slack 13.1 : /etc/udev/rules.d70-persistent-net.rules Ramurd Slackware 10 02-18-2011 09:56 AM
70-persistent-net.rules DebianUser Linux - Networking 1 08-07-2010 07:09 AM
cat: /etc/udev/rules.d/70-persistent-net.rules: No such file or directory rcg1984 Linux From Scratch 2 09-17-2008 07:02 AM


All times are GMT -5. The time now is 02:09 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration