Bugzilla – Bug 557617
capiinit fails because of bad udev capi rule
Last modified: 2011-01-17 17:39:56 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.4) Gecko/20091016 SUSE/3.5.4-1.1.2 Firefox/3.5.4 The capiinit command fails with an error message: xenon:/home/ts # capiinit ERROR: cannot open /dev/capi20 nor /dev/isdn/capi20 - Is a directory (21) /var/log/messages shows: Nov 22 16:12:43 xenon kernel: [ 191.136739] capifs: Rev 1.1.2.3 Nov 22 16:12:43 xenon udevd-work[3696]: rename(/dev/capi/.udev-tmp, /dev/capi/) failed: Not a directory Nov 22 16:12:43 xenon kernel: [ 191.167367] capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs) Editing /etc/udev/rules.d/45-isdn.rules and moving the line KERNEL=="capi*", NAME="capi/%n" one line up, so that it precedes the line KERNEL=="capi", NAME="capi20", SYMLINK+="isdn/capi20" fixes the problem. Problem appears to be the same as Fedora/Red Hat Bug 507241, see https://bugzilla.redhat.com/show_bug.cgi?id=507241 Reproducible: Always Steps to Reproduce: 1. Boot system. 2. Run capiinit as root. Actual Results: Error message: ERROR: cannot open /dev/capi20 nor /dev/isdn/capi20 - Is a directory (21) Device file /dev/capi20 does not appear. Expected Results: No error message. Device file /dev/capi20 appears.
The issue is part of i4l-base, not udev.
*** Bug 556236 has been marked as a duplicate of this bug. ***
Created attachment 329421 [details] new isdn rules file Any chance, to check if replacing: /etc/udev/rules.d/45-isdn.rules with the attached file makes it work?
I just tested this attachment on an openSUSE 11.2 32bit System with an AVM ISDN PCI card (copied the file as 45-isdn.rules into /etc/udev/rules.d). With the original installation the capi20 device was not created. Now after reboot the isdn card seems to work - capiinfo show the normal capi information. For me it works!
Yes, it does. With the new 45-isdn.rules file, all is well: - capiinit runs without emitting an error message - /dev/capi20 appears - capiinfo correctly reports the installed controllers
Forgot to mention: I tested on an openSUSE 11.2 64bit install with a Siemens Gigaset SX255 USB ISDN device.
Assigning to Reinhard. Thanks! (Attached is an update for the shipped udev rules in i4l-base, which seem to broken for a long time.)
What's the addition of ENV{SYSCONFIG}="no" to the usb and pcmcia lines about? It does not seem to be related to this bug.
It's a left-over from ancient times of sysconfig. These variables don't exist anymore. It was once used when sysconfig was loading kernel modules on SUSE, but this is replaced by udev on all common distros for a long time now.
Thanks Kay, and sorry for the confusion. It was of course a removal and not an addition, I somehow read the patch in the wrong direction... I've committed i4l-base to the network:telephony project. Can you guys please test the new package once it appears on http://download.opensuse.org/repositories/network:/telephony/ ?
Just installed the packages in the repository build on Dec 2. Server restarted - capi works. Test passed here (openSUSE 11.2 32bit, AVM Fritz!PCI)
Installing the version from network:telephony repository has fixed the problem for me: ts@xenon:~> rpm -q i4l-base i4l-base-2009.9.16-7.1.x86_64 ts@xenon:~> cat /etc/SuSE-release openSUSE 11.2 (x86_64) VERSION = 11.2 ts@xenon:~> sudo /sbin/capiinit ts@xenon:~> ls -l /dev/capi20 crw-rw---- 1 root dialout 68, 0 3. Dez 14:49 /dev/capi20 ts@xenon:~> capiinfo Number of Controllers : 1 Controller 1: Manufacturer: Siemens CAPI Version: 2.0 Manufacturer Version: 0.0 Serial Number: 0 BChannels: 2 Global Options: 0x00000011 internal controller supported Supplementary Services supported B1 protocols support: 0x00000003 64 kbit/s with HDLC framing 64 kbit/s bit-transparent operation B2 protocols support: 0x00000002 Transparent B3 protocols support: 0x00000001 Transparent 0000 0200 11000000 03000000 02000000 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Supplementary services support: 0x00000000 ts@xenon:~> Hardware: Siemens Gigaset SX255 connected via USB Thanks, Tilman
(In reply to comment #10) > I've committed i4l-base to the network:telephony project. Did we get an online update with this patch? Detlef
Push: Online update?
As openSUSE is abandoning ISDN support which is essential for me, I'll move to a different distribution. Consequently I won't be available for questions concerning this bug anymore.
Was there some sort of official announcement saying we abandoned ISDN? I'm technically the maintainer for ISDN but only because I inherited it when the engineer who maintained it left Novell. I don't have any ISDN hardware or experience with the service, so I'm not exactly able to offer much in the way of assistance but I hadn't heard anything in the way of an official message. As openSUSE is a community distribution, ISDN support would really depend on someone stepping up to maintain it who actually has some experience with it.
See Bug 608790, comment 5. Summary: Configuration of ISDN devices via YaST is broken and won't be fixed for lack of resources. NB: SuSE's ISDN support is entirely geared to YaST. Setting up an ISDN device on openSUSE without YaST is complicated and largely undocumented. Consequently, leaving the YaST ISDN module broken turns openSUSE from a distribution particularly suited for use with ISDN (which was the reason why I chose it a long time ago) to one particularly difficult to use with ISDN (which is why I am reverting this choice now). NB2: I am well aware that openSUSE is a community distribution. However the openSUSE community is obviously not interested in ISDN anymore. Not fixing such a fundamental problem which effectively prohibits the use of ISDN devices was really only the last straw in a long chain. (I may still be able to dig out the bug numbers if you're interested.) I have enough on my plate with maintaining an ISDN kernel driver in my spare time. I cannot on top of that analyze, fix and maintain the YaST2 ISDN module all on my own, seeing that there's no one left to even answer questions about its inner workings. For me, the most sensible course of action is therefore to switch to an alternative distribution which at least doesn't get in the way of using ISDN devices.
This was fixed for 11.3. Closing as FIXED.
That issue is repaired in 11.3 but Yast isdn module ist still broken and unuseable in 11.3. Theres no way to set up an ISDn device without editing config files. see: https://bugzilla.novell.com/show_bug.cgi?id=608790 olly