Summary:	ASTERISK-07345: /dev/zap directory not being built.
Reporter:	Rehan Khan (rasker)	Labels:
Date Opened:	2006-07-16 06:45:19	Date Closed:	2007-03-15 23:50:19
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	similar (or the same as) to http://bugs.digium.com/view.php?id=5246&nbn=3  (ZAP-77) After multiple re-installs the /dev/zap is not being created. The fix posted in ZAP-77 appears to work. ztdummy loads after manually creating the directory and the links. Zaptel is being installed to provide timing only as no zap cards are installed in this machine. I have posted this as the ZAP-77 states that it cannot be reproduced. ****** ADDITIONAL INFORMATION ****** Config: Dell Hardware Centos 4.3 kernel 2.6.9-34.0.2 EL Asterisk SVN-branch-1.2-r34875M udev 0.94 (upgraded to latest, original was 0.39) zaptel 1.2.6, zaptel 1.2.7, zaptel 1.2.6-1.1104 (SVN) Zaptel was originally installed as an RPM (from the Trixbox install sources). The RPM was removed so that zaptel could be built from sources. However just getting ztdummy up and running has never worked (I believe) Using a genzaptelconf command (AAH ot Trixbox specific?) I see that the rules file is being copied accross in the new udev (post 0.50) format (rules and permissions in the same line). I have added the udev rules and permissions in the old format (as detailed in readme.udev) as well and this did not correct the problem. I tried the zaptel from the 1.2 branch and from trunk. Same issue. I tend to agree that this may be a udev issue. However the /dev/zap is not being created so it may be an issue in the driver compile. commands used to build driver: make clean make linux26 make install manually doing a modprobe zaptel and modprobe ztdummy did load the modules (they are listed in lsmod). Starting zaptel using 'service zaptel start' sucessfully starts zaptel but fails when loading the ztdummy driver.
Comments:	By: Rehan Khan (rasker) 2006-07-16 06:47:38 BTW I also ran 'make devices' to no avail. By: Rehan Khan (rasker) 2006-07-16 06:49:29 I guess I can reproduce this by manually deleting the /dev/zap directory and trying to get ztdummy to load if required. Let me know. The box is in production so I will have to schedule some downtime. By: Tilghman Lesher (tilghman) 2006-07-16 09:51:13 Have you followed the instructions in README.udev ? By: Rehan Khan (rasker) 2006-07-16 11:02:10 Yes. As I said in the additional notes above I have tried many variations (including the original detailed in readme.udev!). Just to fill out the explanation from my investigations: There are two flavours of udev. One udev pre-0.50 and one post0.50. One of the main differences between these two versions is the formatting of the permissions.d and rules.d files. The difference is that the entries in the rules.d directory files can now be put in the permissions.d directory files. The readme.udev covers how the entries should look like in the 'old' format. I tried these. I have the 0.94 version of udev. So I also tried the new format (actually the Trixbox install creates the new format anyway). The zapctl entry exists so udev should create the charachter device /dev/zapctl. However loading the driver errors on /dev/zap. this directory does not seem to be created by udev for some reason. I will check the files again because I don't remember there being an entry for /dev/zap/ctl. I can manually create the files on each reboot and I can load the driver. New information: the /dev/zap directory is lost on a reboot. I would really like to get the zaptel driver working properly as I will need to use the TDMoE connectivity in the future. Cheers. By: Tilghman Lesher (tilghman) 2006-07-16 14:54:19 This would appear to be a CentOS issue.  I suggest that you file a bug with them, as we are unable to reproduce this issue. By: Rehan Khan (rasker) 2006-07-16 21:03:31 After a great deal of tomfoolery...... It is a udev issue however the issue is caused by the genudevrules script in the zaptel buildtools directory (i am assuming that this script is used to create the zaptel.rules file during install). The script writes out the zaptel.rules file as follows: # zaptel devices with ownership/permissions for running as non-root KERNEL${match}"zapctl", NAME="zap/ctl", OWNER="asterisk", GROUP="asterisk", MODE="0660" KERNEL${match}"zaptimer", NAME="zap/timer", OWNER="asterisk", GROUP="asterisk", MODE="0660" KERNEL${match}"zapchannel", NAME="zap/channel", OWNER="asterisk", GROUP="asterisk", MODE="0660" KERNEL${match}"zappseudo", NAME="zap/pseudo", OWNER="asterisk", GROUP="asterisk", MODE="0660" KERNEL${match}"zap[0-9]*", NAME="zap/%n", OWNER="asterisk", GROUP="asterisk", MODE="0660" It appears that this is incorrect. There should only be a comma after the kernel option and then space is used as a separator. So the script should write out : # zaptel devices with ownership/permissions for running as non-root KERNEL${match}"zapctl", NAME="zap/ctl" OWNER="asterisk" GROUP="asterisk" MODE="0660" KERNEL${match}"zaptimer", NAME="zap/timer" OWNER="asterisk" GROUP="asterisk" MODE="0660" KERNEL${match}"zapchannel", NAME="zap/channel" OWNER="asterisk" GROUP="asterisk" MODE="0660" KERNEL${match}"zappseudo", NAME="zap/pseudo" OWNER="asterisk" GROUP="asterisk" MODE="0660" KERNEL${match}"zap[0-9]*", NAME="zap/%n" OWNER="asterisk" GROUP="asterisk" MODE="0660" If the debug is turned on in /etc/udev/udev.conf the original rules return parsing errors and are skipped which is why the /dev/zap is not built. With the changes in place everything works fine. (this has been tested on two machines, one in the UK and one in Croatia, both Dells). The README.udev (old udev rules file) then only applies to udevs prior to 0.46. It should probably be updated to reflect that the permissions.d changes are a must (the text says 'may wish') for these older revision udevs when asterisk is running non-root. I am not sure why this is the case as much of the udev documentation I have seen has the commas in place. At a guess the statements that match against the device should be separated by commas and the generated device names and permissions should not. (The solution was discovered by comparing the zaptel.rules with rules generated for vISDN.) Cheers Rehan By: Rehan Khan (rasker) 2006-07-16 21:31:10 Additional info: As the genudevrules script correctly says it is not clear when the permissions were merged with the rules (i've checked and it is not clear!) it seems that this was first implemented in 0.46 where the changelog states in the Kay Sievers section: simplify permission handling From this point on the existing permission entries are migrated to to the rules files at varying times for various flavours of Linux. So the genudevrules script could probably be modified to automatically write out the old rules for udev prior to 0.46. Rehan By: Rehan Khan (rasker) 2006-07-16 21:45:35 Without further testing this may only apply to the 'virtual' zaptel drivers (e.g. ztdummy) on machines without an actual zaptel card. I am assuming that the genudevrules works somehow as it is currently for machines that have a zaptel card (otherwise it would not be in the drivers?). R By: Tzafrir Cohen (tzafrir) 2006-08-12 12:21:39 Unrelated issue: latest commit of genzaptelconf in zaptel trunk tells it to wait for the creation of /dev/zap after loading the modules. Aparantly in some cases it takes a while and this could fail the running of ztcfg in genzaptelconf. Your last comment, though, makes no sense. Those device files are generated by the module zaptel regardless of which other spans/channels exist. By: Serge Vecher (serge-v) 2006-08-25 11:19:55 closing time? By: Rehan Khan (rasker) 2006-08-25 19:42:25 Not sure it has been fixed. The 'new' udev rules used by zaptel are incorrect. they will not build the required directories correctly in /dev/zap in thier current format. The permissions will probably not be applied although the directories will be made. As they are incorrect udev probably just uses the default root, root permissions. This is why the old udev rules still need to be used as they will work and the new rules are skipped over with silent errors. This may be an issue for me as asterisk runs as 'asterisk' user and the root, root permissions will prevent asterisk from accessing the driver. If there is hardware in the machine then there will be device directories in /sys. Thus udev will build /dev directories despite the fact the rules may be wrong. If there is no hardware installed (ztdummy) then these directories are not automatically built and the permissions.d file becomes more important. Thus the error is highlighted in a no zaptel hardware install but still exists in a machine with the hardware. I'll be working on this next week and can put something together to apply the correct rules according to the udev version. As udev will stop supporting the old format at sometime (post v1.0) it's probably a good idea to get this nailed now. Rehan By: jmls (jmls) 2006-11-01 13:00:40.000-0600 rasker: any news on this ? By: Tzafrir Cohen (tzafrir) 2007-01-09 01:56:09.000-0600 Set status to feedback or close? Rules seem to be fine. permissions can be set by tweaking them (see udev(7)) By: Clod Patry (junky) 2007-02-18 00:23:15.000-0600 rasker: ping By: Serge Vecher (serge-v) 2007-03-14 08:36:48 tzafrir: can you please advise on how to proceed here? By: Tzafrir Cohen (tzafrir) 2007-03-15 23:50:17 While I suspect the udev rules, let's please verify that they are to blame. If you still have problems, please provide the following:  grep zap /etc/udev/rules.d/*  ls /sys/class/zaptel  ls /dev/zap Note: if static generation of device files is needed even though you have udev, this is a bug, and a valid cause for re-opening this issue.