+++ This bug was initially created as a clone of Bug #228265 +++ This seems to be the same problem as reported in the bug: homealone[2]cat /etc/udev/rules.d/10-local.rules DRIVERS=="ivtv", ATTR{name}=="ivtv? encoder MPEG", SYMLINK+="pvr150_video" DRIVER=="ivtv", SYSFS{name}=="BT878 video _ ___ UNKNOWN/GENER", SYMLINK+="bt878_video" DRIVERS=="ivtv", ATTRS{name}=="ivtv? encoder VBI", SYMLINK+="pvr150_vbi" DRIVER=="ivtv", SYSFS{name}=="BT878 vbi _ ___ UNKNOWN/GENER", SYMLINK+="bt878_vbi" The symlink /dev/pvr150_video does not get created but /dev/pvr150_vbi does. udevtest claims that both should be created: homealone[2]udevtest /class/video4linux/vbi1 parse_file: reading '/etc/udev/rules.d/05-udev-early.rules' as rules file parse_file: reading '/etc/udev/rules.d/10-libifp.rules' as rules file parse_file: reading '/etc/udev/rules.d/10-local.rules' as rules file parse_file: reading '/etc/udev/rules.d/40-multipath.rules' as rules file parse_file: reading '/etc/udev/rules.d/50-udev.rules' as rules file parse_file: reading '/etc/udev/rules.d/60-libmtp.rules' as rules file parse_file: reading '/etc/udev/rules.d/60-libnjb.rules' as rules file parse_file: reading '/etc/udev/rules.d/60-libsane.rules' as rules file parse_file: reading '/etc/udev/rules.d/60-net.rules' as rules file parse_file: reading '/etc/udev/rules.d/60-pcmcia.rules' as rules file parse_file: reading '/etc/udev/rules.d/60-wacom.rules' as rules file parse_file: reading '/etc/udev/rules.d/85-pcscd_ccid.rules' as rules file parse_file: reading '/etc/udev/rules.d/85-pcscd_egate.rules' as rules file parse_file: reading '/etc/udev/rules.d/90-alsa.rules' as rules file parse_file: reading '/etc/udev/rules.d/90-hal.rules' as rules file parse_file: reading '/etc/udev/rules.d/95-pam-console.rules' as rules file parse_file: reading '/etc/udev/rules.d/99-fuse.rules' as rules file parse_file: reading '/etc/udev/rules.d/bluetooth.rules' as rules file This program is for debugging only, it does not create any node, or run any program specified by a RUN key. It may show incorrect results, if rules match against subsystem specfic kernel event variables. main: looking at device '/class/video4linux/vbi1' from subsystem 'video4linux' udev_rules_get_name: add symlink 'pvr150_vbi' udev_rules_get_name: no node name set, will use kernel name 'vbi1' udev_device_event: device '/class/video4linux/vbi1' already in database, validate currently present symlinks udev_node_add: creating device node '/dev/vbi1', major = '81', minor = '225', mode = '0660', uid = '0', gid = '0' udev_node_add: creating symlink '/dev/pvr150_vbi' to 'vbi1' main: run: 'socket:/org/kernel/udev/monitor' main: run: 'socket:/org/freedesktop/hal/udev_event' main: run: '/sbin/pam_console_apply /dev/vbi1 /dev/pvr150_vbi' homealone[2]udevtest /class/video4linux/video1 ....(Same as above) main: looking at device '/class/video4linux/video1' from subsystem 'video4linux' udev_rules_get_name: add symlink 'pvr150_video' udev_rules_get_name: no node name set, will use kernel name 'video1' udev_db_get_device: found a symlink as db file udev_device_event: device '/class/video4linux/video1' already in database, validate currently present symlinks udev_node_add: creating device node '/dev/video1', major = '81', minor = '1', mode = '0660', uid = '0', gid = '0' udev_node_add: creating symlink '/dev/pvr150_video' to 'video1' main: run: 'socket:/org/kernel/udev/monitor' main: run: 'socket:/org/freedesktop/hal/udev_event' main: run: '/sbin/pam_console_apply /dev/video1 /dev/pvr150_video' Also it did work about a day or so ago. I make daily updates of f7 from repositories and udev is the following version: homealone[2]rpm -qf /etc/udev/rules.d/ udev-106-4.fc7
does the problem still exist with the newer udev updates?
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there have not been any updates to the report since thirty (30) days or more since we requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance. Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.