Hide Forgot
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:
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/