This is not the same problem as that other "capi20 missing" bug from a year ago. Apparently, udev doesn’t create /dev/capi20 anymore, and hence /etc/init.d/capi, and all services depending on it, fail. When running “mknod /dev/capi20 c 68 0”, it works again. But of course I don’t know what permissions, user/group and symlinks it were supposed to have, and what other related devices (“/dev/{capi,isdn}/*”?) might be missing too. And so, only restoring the original udev rules might make it clean again. Reproducible: Always Steps to Reproduce: 1. Make sure your kernel supports CAPI and the CAPIfs (deprecated, but still needed for CAPI) 2. /etc/init.d/capi start # or restart Actual Results: /etc/init.d/capi fails because /usr/sbin/capiinit can’t find /dev/capi20 or related files. But since /usr/sbin/capiinit’s output is redirected to /dev/null, no error is shown, except for the [ !! ]. Expected Results: Since udev created /dev/capi20 and related files properly, /usr/sbin/capiinit can load, and hence “/etc/init.d/capi start” succeeds. This stopped working a couple of weeks ago. The whole situation for running capisuite is desperate. Since apparently /etc/init.d/capi can't handle mISDN in a way that makes it usable as CAPI (e.g. for capisuite), and the fcpci driver has to be manually compiled and installed to access my card and be able to continue running my answering machine on it at all. Maybe it would be better to just explain how to run /etc/init.d/capi in a way that mISDN and avmfritz (the mISDN version of fcpci) can be used below capisuite…
Try moving most of it into a forum question (you may drop a link to it here, if you like). The initial part of the problem seems to lie in the init script - it seems it should check for /dev/capi, not /dev/capi20 - see if this helps to get things started.
(In reply to comment #1) > it seems it > should check for /dev/capi, not /dev/capi20 - see if this helps to get things > started. Well, that wouldn’t work, since /usr/sbin/capiinit still expects /dev/capi20. But ln -s /dev/capi /dev/capi20 worked. Obvious, since they both have the same device numbers. But the more important question is: Who went and renamed the device without checking with its init script first? –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– So let’s correct this bug to: Please either undo the renaming of the device node (simple and obvious choice), or change the init script, net-dialup/capi4k-utils, and everything else that accesses the file. :)
Ok, the symlink does work for capi but not for capisuite. I had to undo everything, and > mknod /dev/capi c 68 0 otherwise it wouldn’t work. Also, after a reboot, the device node is gone again, obviously. So this needs permanent fixing like described in the last comment.
Once again, forum would be a better place for this. /dev/capi is the proper name for the node -the only possible fix for udev would be adding a /dev/capi20 symlink and setting the group to uucp. So, what did you mean by "does work for capi but not for capisuite" ?
(In reply to comment #4) > Once again, forum would be a better place for this. The /etc/init.d/capi script doesn’t work, capiinit fails, and you tell me it’s my problem and not a bug? … Please! ;) > /dev/capi is the proper name for the node -the only possible fix for udev would > be adding a /dev/capi20 symlink and setting the group to uucp. Well, I have no problem with the name change. If the software is changed with it, so that it still works. That’s a reasonable expectation, isn’t it? ^^ uucp? I thought dialup… Ok, I’ll just see whatever it was back when it still worked, when it’s added to the current udev. Since currently /dev/capi is just root:root. > So, what did you mean by "does work for capi but not for capisuite" ? In its logs, CapiSuite says: > CapiSuite 0x5ab69958: Can't start Capi abstraction. The given error message was: CapiError: Error in CAPI20_ISINSTALLED: CAPI not installed. occured in \ Capi::getCapiInfo()
:roll: have patience The real problem here is that both capi4k-utils and capisuite aren't alive upstream anymore. There might be a need for a patch to capi4k-utils after we're done. For the moment: - change /dev/capi20 to /dev/capi anyway (I'd say that this will be the proper long term solution anyway, not adding a legacy symlinks to udev) - create /dev/capi20 symlink to /dev/capi Post what capisuite prints afterwards.
(In reply to comment #6) > The real problem here is that both capi4k-utils and capisuite aren't alive > upstream anymore. Aaaah, capi4k-utils too? See, I didn’t know that. I’m completely open to a replacement. As long as the script I use as my “answering machine” in capisuite would still works. Because, well, I’s a long-grown complex intelligent system that is closer to a AI butler taking calls than to an answering machine. :) I know that Asterisk is a huge overengieered mess, which makes it really hard to adapt my script to it. (Yes, *that* really would have to go to the forums rather than this bug. So I’ll stop about that now. :) > There might be a need for a patch to capi4k-utils after we're done. Yes, most likely. > For the moment: > - change /dev/capi20 to /dev/capi anyway (I'd say that this will be the proper > long term solution anyway, not adding a legacy symlinks to udev) OK… > - create /dev/capi20 symlink to /dev/capi That’s what I already had done back in comment #3/#2. And while /etc/init.d/capi starts, > Post what capisuite prints afterwards. this is what CapiSuite said: > CapiSuite 0x5ab69958: Can't start Capi abstraction. The given error message was: CapiError: Error in CAPI20_ISINSTALLED: CAPI not installed. occured in \ Capi::getCapiInfo()
The ebuild's version is capi4k-utils-20050718 - looking at the calendar, I wouldn't call that "alive". As I said, have patience or most likely result will be like bug 346179. That error comes actually from capi4k-utils after open(capidevname, O_RDWR) fails. Unfortunately, that's sort of hardcoded (it's either /dev/capi20 or /dev/isdn/capi20) What's the output of 'groups' for root and 'ls -l /dev/capi' ?
I am assigning this to the capi4k maintainers since it isn't really a udev bug and since there has been no activity on it for months. I think that capi4k should be patched for this.
CCing treecleaners
This has still many reverse deps... but I don't know what alternative is being used in other distributions as we are the only ones still having this package :/
If it’s just me…: I fully migrated to SIP, and have no use for this anymore. (It served me well in protecting me from a telephone stalker for years.) If nobody complains, I have no objections with deprecating this package.
# Michał Górny <mgorny@gentoo.org> (05 Jun 2017) # (on behalf of Treecleaner project) # Abandoned upstream and downstream. Reported not to work. CAPI flags # in reverse dependencies are masked for some time already. # Removal in 30 days. Bug #379975. net-dialup/capi4k-utils
commit 70ce185e0296b1895ec3fc9ec69ef9857f940c14 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Wed Jul 5 12:19:20 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Wed Jul 5 12:35:15 2017 net-dialup/capi4k-utils: Remove last-rited pkg, #379975
