Bug 134525 - isdn does not provide /sys/class/*/dev
Summary: isdn does not provide /sys/class/*/dev
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Woodhouse
QA Contact:
: 133889 (view as bug list)
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-10-04 13:19 UTC by Harald Hoyer
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-12-07 06:16:32 UTC

Attachments (Terms of Use)

Description Harald Hoyer 2004-10-04 13:19:07 UTC
udev does not create any devices, because the isdn modules do not
provide a dev file in /sys.

ll /dev/isdn*
crw-------  1 root root 45,   0 Feb 23  2004 /dev/isdn0
crw-------  1 root root 45,  64 Feb 23  2004 /dev/isdnctrl0

Comment 1 Ngo Than 2004-10-04 13:26:58 UTC
*** Bug 133889 has been marked as a duplicate of this bug. ***

Comment 2 Ngo Than 2004-10-04 13:53:29 UTC
ippp* devices are missing.

ll /dev/ippp*

crw-------  1 root root 45, 128 Feb 23  2004 /dev/ippp0

Comment 3 Harald Hoyer 2004-10-04 14:03:07 UTC
workaround: create the devices in the isdn initscript with MAKEDEV

Comment 4 A. Folger 2004-10-04 18:14:43 UTC
Could you please provide the exact command line for this MAKEDEV?


Comment 5 Uwe Beck 2004-10-04 21:05:21 UTC
The RHEL4-BETA1 kernel rpms (kernel-2.6.8-1.528.2.10) does not provide
isdn modules. If you configure ISDN in the kernel and compile an own
kernel, the isdn modules can only load with modprobe. "service isdn
start" load the isdn module, does not found the /dev/isdn* and unload
the isdn modules. The reason for this is that /sys/class/*/dev do not
contain isdn and udev can not create the relevant device files in
/dev. If you create the device files with MAKEDEV you can use isdn
until you reboot the system new.

For RHEL4 we need a correct isdn implementation.

Comment 6 Harald Hoyer 2004-10-05 08:39:41 UTC
Permanent workaround:
# /sbin/MAKEDEV -d /etc/udev/devices isdn

Comment 7 Ngo Than 2004-10-05 14:41:47 UTC
i have added a workaround in isdn4k-utils-3.2-18.p1.1, which creates
the missing isdn/ippp devices.

Comment 8 A. Folger 2004-10-05 20:16:40 UTC
I tried Harald Hoyer's workaround and it didn't work. So I issued the
same command with /dev/ as the target directory, and things work,
however, I fear this will become useless by the next reboot, until I
reissue the command. So, I assume I must be missing a little part of
the advise HH must have assumed I knew.

As far as the updated isdn4k-utils-3.2-18.p1.1 of Ngo Than, I will be
very grateful to try it, but have not found it on the mirror I
checked. Could you post a URL?

NOTE: I am using an AMD64 (Fedora for x86_64).

Comment 9 Warren Togami 2004-10-05 20:27:22 UTC
Is the comment #7 workaround SELinux safe?

Comment 10 Harald Hoyer 2004-10-06 08:14:32 UTC
Warren, the isdn initscript uses /sbin/MAKEDEV ... so, I assume, yes.

Comment 11 Tim Burke 2004-10-11 22:56:46 UTC
ISDN got inadvertently omitted from earlier kernels, but should be
back in now.

Comment 12 Bill Nottingham 2004-10-15 15:48:27 UTC
Does this work now for people with currenet devel packages?

Comment 13 A. Folger 2004-10-16 19:41:40 UTC
[afolger@localhost ~]$ rpm -qa |grep isdn
[afolger@localhost ~]$ rpm -q kernel
[afolger@localhost ~]$

With the above, isdn works fine. The only problem is that the GUI
doesn't recognize that the interface is up and running (status remains


Comment 14 Ngo Than 2004-10-18 08:05:52 UTC
i think it's better if we add the workaround in initscript instead
isdn4k-utils. it will fix this problem

Comment 15 Ngo Than 2004-10-18 09:09:26 UTC
it looks like you did not start start isdn cript (/etc/init.d/isdn
start) before using GUI. Could you please try to start isdn service
before. Does the problem still appear?

Comment 16 Uwe Beck 2004-10-18 09:45:47 UTC

look for http://people.redhat.com/harald/udev.html
 -> "But I really want my device node!"

isdn4k-utils can create the devices during the rpm installation as post.

/sbin/MAKEDEV -d /etc/udev/devices isdn ippp

In RHEL4_BETA1 there is only the udev-030-26 version. Do not work with
this version. A newer version of udev is not available for RHEL4_BETA?
What do you think about that?

Comment 17 Ngo Than 2004-10-18 09:53:21 UTC
Uwe, the current isdn4k-utils in rawhide should work with udev-030-26.

Comment 18 Uwe Beck 2004-10-18 10:02:11 UTC
Yes, the workarount in isdn4k-utils-3.2-18.p1.1 works with udev-030-26
at this time.

Comment 19 A. Folger 2004-10-18 14:48:07 UTC
Replying to #15. I assume you were reacting to my #13 (without 
threading, this system is reaching its limit on bugs such as ours). 
I am using runlevel 5, so that I don't have a chance to run 
startisdn. In fact, I discovered that the GUI (System->network device 
control) starts ISDN services, as before that I cannot start ISDN 
using /sbin/isdnctrl dial ippp0 from the command line. 
So, indeed, I am not running startisdn before the GUI. But neither 
will most users. This is an issue that deserves fixing. 

Comment 20 Bill Nottingham 2004-10-20 06:04:22 UTC
Whatever runlevel you're using, the isdn service *should* be running
in it if you need isdn.

Comment 21 Ngo Than 2004-10-20 09:04:51 UTC
The isdn service always starts at boot as default. it's off in your
case. You have to enable isdn service again, (chkconfig isdn on).

it looks like someone has disabled ISDN service on your machine?

Comment 22 A. Folger 2004-10-20 13:46:34 UTC
Well, it is off by default. The computer tries to start isdn services 
at boot, but invariably fails. Any ideas? 

Comment 23 Ngo Than 2004-10-21 13:57:20 UTC
if it's off by default in your case, please enable it again with

  chkconfig isdn on

it should work by next reboot. I have verified it on my local machine.

Comment 24 Dave Jones 2005-12-01 06:46:45 UTC
this has been in MODIFIED state for over a year, which leads me to believe its
fixed.  Can you confirm ?

Comment 25 A. Folger 2005-12-06 12:47:32 UTC
Yes, it works. 

Note You need to log in before you can comment on or make changes to this bug.