This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 134525 - isdn does not provide /sys/class/*/dev
isdn does not provide /sys/class/*/dev
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
:
: 133889 (view as bug list)
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-10-04 09:19 EDT by Harald Hoyer
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-07 01:16:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Harald Hoyer 2004-10-04 09:19:07 EDT
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 09:26:58 EDT
*** Bug 133889 has been marked as a duplicate of this bug. ***
Comment 2 Ngo Than 2004-10-04 09:53:29 EDT
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 10:03:07 EDT
workaround: create the devices in the isdn initscript with MAKEDEV
Comment 4 A. Folger 2004-10-04 14:14:43 EDT
Could you please provide the exact command line for this MAKEDEV?

afolger@aishdas.org
Comment 5 Uwe Beck 2004-10-04 17:05:21 EDT
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 04:39:41 EDT
Permanent workaround:
# /sbin/MAKEDEV -d /etc/udev/devices isdn
Comment 7 Ngo Than 2004-10-05 10:41:47 EDT
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 16:16:40 EDT
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 16:27:22 EDT
Is the comment #7 workaround SELinux safe?
Comment 10 Harald Hoyer 2004-10-06 04:14:32 EDT
Warren, the isdn initscript uses /sbin/MAKEDEV ... so, I assume, yes.
Comment 11 Tim Burke 2004-10-11 18:56:46 EDT
ISDN got inadvertently omitted from earlier kernels, but should be
back in now.
Comment 12 Bill Nottingham 2004-10-15 11:48:27 EDT
Does this work now for people with currenet devel packages?
Comment 13 A. Folger 2004-10-16 15:41:40 EDT
[afolger@localhost ~]$ rpm -qa |grep isdn
isdn4k-utils-3.2-18.p1.1
[afolger@localhost ~]$ rpm -q kernel
kernel-2.6.8-1.603
[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
inactive).

AF
Comment 14 Ngo Than 2004-10-18 04:05:52 EDT
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 05:09:26 EDT
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 05:45:47 EDT
Than,

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 05:53:21 EDT
Uwe, the current isdn4k-utils in rawhide should work with udev-030-26.
Comment 18 Uwe Beck 2004-10-18 06:02:11 EDT
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 10:48:07 EDT
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 02:04:22 EDT
Whatever runlevel you're using, the isdn service *should* be running
in it if you need isdn.
Comment 21 Ngo Than 2004-10-20 05:04:51 EDT
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 09:46:34 EDT
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 09:57:20 EDT
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 01:46:45 EST
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 07:47:32 EST
Yes, it works. 

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