Red Hat Bugzilla – Bug 134525
isdn does not provide /sys/class/*/dev
Last modified: 2007-11-30 17:10:50 EST
udev does not create any devices, because the isdn modules do not
provide a dev file in /sys.
crw------- 1 root root 45, 0 Feb 23 2004 /dev/isdn0
crw------- 1 root root 45, 64 Feb 23 2004 /dev/isdnctrl0
*** Bug 133889 has been marked as a duplicate of this bug. ***
ippp* devices are missing.
crw------- 1 root root 45, 128 Feb 23 2004 /dev/ippp0
workaround: create the devices in the isdn initscript with MAKEDEV
Could you please provide the exact command line for this MAKEDEV?
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.
# /sbin/MAKEDEV -d /etc/udev/devices isdn
i have added a workaround in isdn4k-utils-3.2-18.p1.1, which creates
the missing isdn/ippp devices.
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).
Is the comment #7 workaround SELinux safe?
Warren, the isdn initscript uses /sbin/MAKEDEV ... so, I assume, yes.
ISDN got inadvertently omitted from earlier kernels, but should be
back in now.
Does this work now for people with currenet devel packages?
[afolger@localhost ~]$ rpm -qa |grep isdn
[afolger@localhost ~]$ rpm -q kernel
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
i think it's better if we add the workaround in initscript instead
isdn4k-utils. it will fix this problem
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?
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?
Uwe, the current isdn4k-utils in rawhide should work with udev-030-26.
Yes, the workarount in isdn4k-utils-3.2-18.p1.1 works with udev-030-26
at this time.
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.
Whatever runlevel you're using, the isdn service *should* be running
in it if you need isdn.
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?
Well, it is off by default. The computer tries to start isdn services
at boot, but invariably fails. Any ideas?
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.
this has been in MODIFIED state for over a year, which leads me to believe its
fixed. Can you confirm ?
Yes, it works.