How can I prevent udevd from renaming eth0 to em1

[Michael H. Warfield]

On Sun, 2012-10-21 at 15:24 +1030, Tim wrote:
> On Sat, 2012-10-20 at 22:41 -0400, Michael H. Warfield wrote:
> > Following his instructions, I ended up with this:
> > 
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> > ATTR{address}=="00:19:b9:13:a8:fc", NAME="eth0"

> Finding it hard to remember the plot, but is that rule set for matching
> something the computer was doing?  (Rather than telling it to name it
> eth0, it's asking if it's called eth0.)  Because, if your network isn't
> called eth0, though you want it to be, then trying to match against an
> eth0 that isn't being used, isn't going to match.

> Isn't the behaviour, find this (rule set), then call it (something of
> your own choosing, named somewhere else in the script/program/config)?

> In which case, remove the name and eth0 clause.

No, this worked for me.  If I included the KERNEL= and the other ATTR=
clauses, it failed but I'm not sure which clause caused it to fail.  JD
is saying it's still failing for him.

Now that being said, there's still some notable differences.  Most of my
machines (some F16 and some F17, some i686 and some x86_64) came up with
p2p1 for interface names and his is coming up em1.  Obviously something
is different.  Also, he's reporting a udevd change of the interface name
in dmesg, which I'm not seeing even on the machines where it's still
changing eth0 to p2p1.  So there's something significantly different in
his set-up and maybe even versions that's making this difference.  I
have one machine I have access to that is not mine that is showing em1
as the interface name and it's an F16 i686 system (older Dell tower).
It shows BOTH that name and that renaming.  If I tinker with it and
break the networking, then I have to drive to that location to fix it.

I did just discover that I have a Dell PowerEdge 2850 on hand that shows
em1 and em2 as well as p3p1 and p3p2 (em1 is the main network
interface).  That beast has F17 on it and udevd is reporting the
interface changes like JD is seeing:

[mhw at toolroom ~]$ dmesg | grep udevd
[    1.717298] udevd[152]: starting version 182
[    3.314207] udevd[264]: renamed network interface eth1 to em2
[    3.350217] udevd[264]: renamed network interface eth1 to p3p1
[    3.642203] udevd[264]: renamed network interface eth1 to p3p2
[    3.647220] udevd[266]: renamed network interface eth0 to em1
[   14.564305] udevd[418]: starting version 182

I can play with the other three interfaces and see what I can accomplish
without risking the whole bloody server and a field trip.  This stuff
has to be coming from somewhere.  I'll report back.

> -- 
> [tim at localhost ~]$ uname -rsvp
> Linux 3.6.2-4.fc17.x86_64 #1 SMP Wed Oct 17 02:43:21 UTC 2012 x86_64
> 
> All mail to my mailbox is automatically deleted, there is no point
> trying to privately email me, I will only read messages posted to the
> public lists.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20121021/b481ce41/attachment-0001.sig>