Bug 669486 - renames existing devices that already have configuration
Summary: renames existing devices that already have configuration
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: biosdevname
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: jordan hargrave
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 501533 672663
TreeView+ depends on / blocked
 
Reported: 2011-01-13 19:17 UTC by Bill Nottingham
Modified: 2014-03-17 03:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 672663 (view as bug list)
Environment:
Last Closed: 2011-01-25 21:10:01 UTC
Type: ---


Attachments (Terms of Use)

Description Bill Nottingham 2011-01-13 19:17:25 UTC
Description of problem:

/etc/sysconfig/network-scripts/ifcfg-eth0:
# Network Interface
DEVICE=eth0
BOOTPROTO=dhcp
DEFROUTE=yes
IPV6INIT=no
ONBOOT=yes
TYPE=Ethernet
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
USERCTL=no
IPV4_FAILURE_FATAL=yes
NAME="System eth0"
HWADDR=00:26:2D:F4:FC:06
PEERDNS=yes
PEERROUTES=yes

/etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x8086:0x10ea (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:26:2d:f4:fc:06", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

However, after booting:

2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:26:2d:f4:fc:06 brd ff:ff:ff:ff:ff:ff
    inet 10.11.231.95/22 brd 10.11.231.255 scope global em1

(NM coped with the device being different, but...)

Version-Release number of selected component (if applicable):

biosdevname-0.3.4-1.fc15.x86_64
udev-164-6.fc15.x86_64

How reproducible:

100%, presumably. Just noticed now.

Steps to Reproduce:
1. ifconfig eth0
2. Hey, where'd my eth0 go?

Comment 1 Matt Domsch 2011-01-25 14:54:01 UTC
I think this is a bug in the biosdevname.rules file.

The current rules skip over invoking biosdevname under these conditions:

SUBSYSTEM!="net", GOTO="netdevicename_end"
KERNEL!="eth*",   GOTO="netdevicename_end"
ACTION!="add",    GOTO="netdevicename_end"

I think we need to add:

NAME=="*", GOTO="netdevicename_end"

such that if another rule sets NAME, we don't invoke biosdevname.  I thought that's what was already happening, but somehow I missed including it.

Comment 2 Matt Domsch 2011-01-25 15:56:29 UTC
That should be:

NAME=="?*", GOTO="netdevicename_end"

Comment 3 Bill Nottingham 2011-01-25 17:55:50 UTC
There's one side case that's not handled here - imagine an image-based deployment where the targeted machines only have a single type of ethernet (or a single ethernet device).

An image for this system would likely include interface configuration files that don't specify a hardware address (and therefore don't do specific mappings), but do specify a device name. Introduction of biosdevname into this scenario could/would break things.

That does, of course, assume they include biosdevname in their package set, which wouldn't happen on upgrade.

Comment 4 Bill Nottingham 2011-01-25 17:57:05 UTC
Completely random aside - the biosdevname rules, as system udev files, go in /lib/udev/rules.d, not /etc.

Comment 5 Bill Nottingham 2011-01-25 18:05:02 UTC
The suggested fix does solve the issue for me.

Comment 6 Matt Domsch 2011-01-25 18:28:18 UTC
Thanks for the test Bill.  I've committed that change upstream.

I'm adding in packaging dump_pirq, so we can debug if necessary.

I'll move the rules to /lib/udev/rules.d also.  Odd, RHEL5 doesn't seem to have that directory...

Comment 7 Bill Nottingham 2011-01-25 18:45:00 UTC
RHEL 5 has frighteningly old udev, alas.

Comment 8 Matt Domsch 2011-01-25 21:09:43 UTC
Build 0.3.6 for F15.

Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2742285
Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=215600


Note You need to log in before you can comment on or make changes to this bug.