Bug 212869

Created attachment 139678 [details]
Output of lspci -vv

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
named.

$ 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
udev-095-14

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

Aurelien Bompard, bind them to the MAC-Address.. HWADDR="" or use
system-config-network to do so.

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.

Just in case anyone else finds this bug irritating, I've come up with a hack to
get around it for network cards:

http://inconnu.islug.org/~ink/new/projects/nicorderer/

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.

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?

http://www.wlug.org.nz/UDev

Another experience and a hack of a solution.

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.

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/*
/dev/video/by-name/*
/dev/video/by-path/*
etc...

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).

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

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
/etc/udev/rules.d/70-persistent-net.rules).

thanks for your update

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.

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

in rawhide we now have with udev-143:

/dev/snd/by-path/
/dev/v4l/by-path/