From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050818 Firefox/1.0.6 Description of problem: /dev/raw1394 now appears in /dev/raw/raw1394 due to /etc/udev/rules.d/50-udev.rules containing: KERNEL=="raw[0-9]*", NAME="raw/%k" probably introduced with: * Thu Oct 14 2004 Harald Hoyer <harald> - 038-1 - raw device nodes are now created in directory raw This line was probably only intended as relocation for /dev/raw, /dev/raw1, /dev/raw2, etc. I say this because: - I find no sign on google whatsoever of /dev/raw/raw1394 being used outside of fedora, or having been used by gentoo by accident (the device is definitely back in /dev/raw1394 at the moment on gentoo) - the script used by Fedora contains no mention of any raw1394-device - the only other script included with the distribution of udev that 1) does relocation of /dev/raw* to /dev/raw/ and 2) mentions raw1394 (this is the gentoo one) contains (notice the comment especially): # IEEE1394 (firewire) devices (must be before raw devices below) KERNEL=="raw1394", NAME="%k", GROUP="video" KERNEL=="dv1394*", NAME="dv1394/%n", GROUP="video" KERNEL=="video1394*", NAME="video1394/%n", GROUP="video" # raw devices KERNEL=="raw[0-9]*", NAME="raw/%k", GROUP="disk" (taken from udev-068 source tarball, etc/udev/gentoo/udev.rules) So in short, every other distribution (judging from the different scripts for different distributions packaged with udev tarball) seems to put the device in /dev, and Fedora seems to put it in /dev/raw by accident. Version-Release number of selected component (if applicable): checked both udev-058-1 and udev-063-6 How reproducible: Always Steps to Reproduce: Install fc4, load the raw1394 module Actual Results: /dev/raw1394 didn't exist, was moved to /dev/raw Expected Results: Device should be named /dev/raw1394 Additional info:
true
From User-Agent: XML-RPC udev-058-1.0.FC4.1 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Great, thanks! Seems to work. It also fixes the /dev/video1394-$i naming of what should have always been /dev/video1394/$i.