Bug 212869 - udev inconsistant naming
Summary: udev inconsistant naming
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 11
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-29 20:55 UTC by Andrew Hamilton
Modified: 2009-06-30 10:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-06-30 10:04:14 UTC
Type: ---

Attachments (Terms of Use)
Output of lspci -vv (14.93 KB, text/plain)
2006-10-29 20:55 UTC, Andrew Hamilton
no flags Details

Description Andrew Hamilton 2006-10-29 20:55:02 UTC
Description of problem:
I have two separate video input cards in my machine (a bttv and saa7130). The
two devices are given random /dev/video[0-1] names upon boot with no apparent
consistency.  On one boot, the saa7130 will be /dev/video0, and the next bttv
will be /dev/video0.  I did not have this trouble in fc5.

Output of uname -a:
Linux localhost.localdomain 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT
2006 i686 athlon i386 GNU/Linux

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

How reproducible:
Almost always.

Steps to Reproduce:
1. Boot system
2. View /dev/video[0-1] association
3. Reboot system
Actual results:
/dev/video[0-1] associations may have changed.

Expected results:
Device names stay the same.

Additional info:

Comment 1 Andrew Hamilton 2006-10-29 20:55:03 UTC
Created attachment 139678 [details]
Output of lspci -vv

Comment 2 Aurelien Bompard 2006-11-11 08:04:33 UTC
I'm having the same problem. I have two network cards, and they swap between
eth0 and eth1. It is *very* problematic for network cards. I also have two
soundcards (one emu10k1 and an USB headset), and they are also inconstistantly

$ uname -a
Linux gauret.homelinux.net 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006
i686 athlon i386 GNU/Linux
$ rpm -q udev

This did not happen in FC5. If you need any more info, I'll be glad to provide.

Comment 3 Harald Hoyer 2006-11-13 10:53:21 UTC
Aurelien Bompard, bind them to the MAC-Address.. HWADDR="" or use
system-config-network to do so.

Comment 4 Craig Kelley 2006-12-18 19:45:45 UTC
I have the same problem with three network cards as well, and we bulk-image
thousands of machines.  Setting HWADDR on each one individually is not really an
option.  We've been able to rely on predictable device names since redhat 7.3.

Comment 5 Craig Kelley 2006-12-20 17:44:36 UTC
Just in case anyone else finds this bug irritating, I've come up with a hack to
get around it for network cards:


I wrote some perl code to take a configuration file (such as 'nic.conf' in that
link) and re-map them back to their device ID (from /sys -- works fine with
PCI).  It uses iproute2 to rename the device.  The init file (nicorderer) is
specific to our application, but can be modified as anyone sees fit, as long as
it runs before /etc/init.d/network does.

Comment 6 Michael Landon 2007-01-04 16:20:18 UTC
This bug applies to audio cards as well.  I have 3 different audio cards in my 
system (on-board Intel-based, PCI C-Media 8738, & PCI Audigy LS 1.0) and the 
card names are not consistent from reboot to reboot.  This appears to be a 
general bug that affects all udev devices.  Is there a workaround for sound 
cards (similar to what Craig Kelley reports above for NICs)?  Fix in progress?

Comment 7 Craig Kelley 2007-01-04 20:38:52 UTC

Another experience and a hack of a solution.

Comment 8 Craig Kelley 2007-01-05 17:41:01 UTC
Another solution is to add all modules that you don't want kmod to load to
/etc/modprobe.d/blacklist and then load them "by hand" in the proper order.

Comment 9 Harald Hoyer 2007-09-20 11:01:09 UTC
not a solution in comment #8 for fedora, I would say.
persistent network and storage naming has been added to F8.
For sound cards and video cards we could come up with a similar solution.
In a perfect world, apps would refer to the hardware not by device names, but by
hardware names.
For network cards it is easy to build unique identifiers because of the mac
address. How would we do that for multiple soundcards/videocards of the same
model? The only solution would be like /dev/disk/*

Comment 10 Craig Kelley 2007-09-20 14:47:56 UTC
I don't think it matters what the identifier is, only that it's deterministic. 
Take two servers of a particular model;  if you want to replace a faulty one
with its twin, you would expect the NICs to come up in the same order even
though the MAC addresses are completely different.  At least, this is the
classic behavior.  It's nice to be able to assign MAC addresses to NICs, but I
think that's beside the point, and particular only to network interfaces (and
you can rename NICs with iproute2 by using the MAC).

Comment 11 Bug Zapper 2008-04-03 18:33:58 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 12 Craig Kelley 2008-04-03 19:14:25 UTC
This is still a problem with Fedora 8.  We need udev persistent rules for sound
and video cards (see /etc/udev/rules.d/75-persistent-net-generator.rules and

Comment 13 John Poelstra 2008-05-05 23:19:18 UTC
thanks for your update

Comment 14 Craig Kelley 2008-05-06 01:52:43 UTC
I would humbly propose using the PCI address for ordering of video and audio
cards.  If a card's PCI address does not have a mapping, assign the next open
one.  If a card DOES have a PCI address mapping, use that one.  This could cause
regressions as well, if, say, the primary audio card dies and only the second
one is available.  I'm not sure what 'default' then becomes in ALSA-land (if
it's even possible to have an ALSA sound card '1' without '0').

I haven't tried this with Fedora 9 yet, but I suspect the bug can be moved to
that target.

Comment 15 Bug Zapper 2008-11-26 07:03:39 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 16 Bug Zapper 2009-01-09 06:59:37 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 17 Bug Zapper 2009-06-09 09:11:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:

Comment 18 Harald Hoyer 2009-06-30 10:04:14 UTC
in rawhide we now have with udev-143:


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