From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6 Description of problem: Same as happen in FC4: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139321 Version-Release number of selected component (if applicable): udev-039-10.8.EL4 How reproducible: Always Steps to Reproduce: 1. put AVM B1 ISDN card into system 2. try to load firmware Actual Results: # /sbin/avmcapictrl load /etc/firmware/isdn/b1.t4 1 Device file /dev/capi20 and /dev/isdn/capi20 missing, use instdev: No such file or directory Expected Results: # /sbin/avmcapictrl load /etc/firmware/isdn/b1.t4 1 Loading Bootcode /etc/firmware/isdn/b1.t4 ... done Additional info:
With AVM PCI (Fritz!PCI v2) isdn card /dev/capi20 also missing.
I tried the udev fix as proposed in the FC4 bug report ([url=https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139321#c5]), but still have issues: 1. using the 'standard' capiinit (from isdn4k-utils package) doesn't work even with the fix - no /dev/capi20 and /dev/capi/* device nodes are created. 2. I compiled capi4k-utils-2005.07.18 which provides a newer capiinit (and some other utilities). With it the first time I run 'capiinit' it fails, but a couple of seconds later the /dev/capi20 and /dev/capi/* device nodes are created. If I run 'capiinit' once more, it starts fine. D.
Your second point looks like to me as the usual udev problem after loading a module (e.g. by a trigger). udev need some time to create the device node (sometimes up to 20 seconds). So one have to debug which code in capiinit triggers loading of module. Here it has to wait some time until the device node is created successfully by udev.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
please test: ftp://people.redhat.com/harald/udev/039-10.14.EL4/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0382.html
It turns out that the rules that were added to fix this are not restrictive enough. They make no distinction between block and character devices. Unfortunately, I don't have one of these devices, so it's tough for me to suggest a new rule to fix it. Would someone with one of these cards be kind enough to run: udevinfo -q all -n /dev/capi20 udevinfo -q all -n /dev/capi/0 and post the output here?
I have still not updated the selinux policy, but here the output as requested: # udevinfo -q all -n /dev/capi20 P: /class/capi/capi N: capi20 T: c M: 020660 S: O: root G: root F: /etc/udev/rules.d/10-capi.rules L: 1 U: 38 R: 0 # udevinfo -q all -n /dev/capi/0 P: /class/tty/capi0 N: capi/0 T: c M: 020660 S: O: root G: root F: /etc/udev/rules.d/10-capi.rules L: 2 U: 38 R: 0