I have been torturing myself for the last week trying to upgrade a Supermicro dual opteron server (64-bit) from a CentOS version 4.4 up to a 5.2, the only two rhel versions my RAID drivers support. In the process, I found that at 4.4, the zaptel modules never loaded, but really never errored significantly (they didn't show FAILED at startup, only that ztcfg was not found and skipped), and asterisk ran with no issues, though I never tried conferencing.
In the process I loaded a replacement 32-bit machine with CentOS 5.3 and a very recent asterisk. All compiled OK on this box, used zaptel and it is actually up and running on a ztdummy. This server is significantly slower than the 64-bit.
I looked back on a Dell x86_64 with CentOS 4.7 that I loaded and it has the same issue as the Supermicro; it looks like zaptel compiled well enough to get the asterisk built, but didn't build and fill /dev/zap. I tried reinstalling with dahdi with the same result, no /dev/dahdi was built.
When I try to use CentOS 5 on the x86_64 servers, zaptel and dahdi both fail because they cannot ever seem to find the kernel sources, no matter how many links I make trying to connect to uname -r. Seems to trace back to yum never finding a kernel-smc-devel for CentOS5, seems strange that I can't find it, it must be replaced by something...
I've tried all sorts of edits in zaptel.conf, /etc/udev/rules.d/50-udev.rules, replacing the spinlock.h file, and several other time wasters.
I guess my question is, has anyone been able to successfully compile zaptel or dahdi on a x86_64, and if so, what OS and steps got them there.
and please don't offer the sage advice:
make clean
./configure
make menuselect
make
make install
make config
'cause I've run that sequence about 666 times now.
do the modules actually
do the modules actually compile? if yes what error are you getting when you type 'service dahdi start' ?
is this for just the dummy
is this for just the dummy drivers or are using telephony hardware? digium support is free for their telephony cards as it pertains to the drivers.
The modules appear to compile
No cards, just the dummy.
Every seems to compile in zaptel. I get "Zaptel build successfully configured" at ./configure, and menuselect goes OK, nothing but the ztdummy selected. At 'make' it shows:
make -C /usr/src/linux ARCH=x86_64 SUBDIRS=/usr/src/zaptel-1.4.12.1/kernel HOTPLUG_FIRMWARE=yes KBUILD_OBJ_M="zaptel.o ztdummy.o modules", no errors that I can see. After 'make install', and it shows "Zaptel installed successfully", and go ahead and run 'make config'. At 'make config' it shows:
"install -D zaptel.init /etc/rc.d/init.d/zaptel
install -D ifup-hdlc /etc/sysconfig/network-scripts/ifup-hdlc
/sbin/chkconfig --add zaptel
Zaptel has been configured.
If you have any zaptel hardware it is now recommended to
edit /etc/default/zaptel or /etc/sysconfig/zaptel and set there an
optimal value for the variable MODULES .
I think that the zaptel hardware you have on your system is:"
At libpri it does flash Wall -Werror -Wstrict-prototypes -Wmissing-prototypes on a lot of lines but still goes through the install without other errors. Then asterisk compiles like nothing happened on top. When I reboot in CentOS 4.4, it shows the zaptel load but it only says 'ztcfg not found' and doesn't say FAILED like usual and skips to the next startup process. When I reboot the box in 4.7, it hangs on the load, eventually says FAILED, and tells me there's nothing in /dev/zap. (or /dev/dhadi, whichever I try). Which there's not, it's not been created. Asterisk and anything related still come up and run without any errors. I'm not sure to care about it so much, but I feel like its one of those things that's going to burn me down the line.
Here's the one from the dell
The supermicro is down now but here's the one from the dell running CentOS 4.7:
[me@pbx01 libpri-1.4.10.1]# lsmod
Module Size Used by
md5 5953 1
ipv6 285729 18
autofs4 28105 0
i2c_dev 13889 0
i2c_core 29121 1 i2c_dev
sunrpc 176697 1
cpufreq_powersave 3265 0
loop 18769 0
button 9313 0
battery 11465 0
ac 6985 0
joydev 12225 0
uhci_hcd 35305 0
ehci_hcd 35013 0
i3000_edac 7369 0
edac_mc 34305 1 i3000_edac
tg3 120133 0
dm_snapshot 19457 0
dm_zero 3905 0
dm_mirror 33865 0
ext3 139729 2
jbd 70001 1 ext3
dm_mod 77609 8 dm_snapshot,dm_zero,dm_mirror
ata_piix 19525 0
libata 125225 1 ata_piix
aacraid 82633 2
sd_mod 19649 3
scsi_mod 146321 3 libata,aacraid,sd_mod
And then someone made the suggestion...
'Did you try just loading a 32-bit CentOS instead of a 64 on your dual-opteron server?'
I guess I should go in that direction. I guess I didn't fully realize that could be done, I was so trying to match the OS to the hardware.
i am sofa king we todd did
well if you want to use all
well if you want to use all the new add-in modules like fax for asterisk and skype (and others) they are only releasing in 32bit versions.
that is too lame
I guess we are supposed to scour the planet for single processor pentium 4s. I wish they'd join us here in the 21st century. And while they're at at, it'd be nice if someone could write something that replaces zaptel/dahdi (especially when you just need the dummy) and maybe the damned compile process altogether, like maybe a stinkin' RPM....
Anyway, no luck on CentOS 5.2 32-bit on the opteron. Could not find the kernel sources thing again. I'm going to try one more time with a 4.4 32-bit. Then I'm gonna call myself nuts and decide whether tomove the license and keep on riding on the 32-bit, single P4 that has it all running right, or go back to what I began with, the opteron running the 64-bit CentOS 4.4 with no zaptel module running.
What a pain in the ass.
who said anything about
who said anything about single processor pentium 4's?
i run 32-bit OS on quad-core intel xen 5400 series all the time. Just because the CPU has 64 bit extensions doesnt mean you have to load that OS. I wouldnt run cent 4.x for anything. The machines I have still running it have been spewing warnings since 1.4.23. I have plently of dadhi systems with 32bit Centos 5.2 on them.
RPM, btw, is a bad idea; its a kernel module. What happens when you update your kernel and your module no longer loads? Hope someone made a new rpm for you that doesn't update itself with rpm -U on non- kernel upgraded systems? DKMS is probably a better route to take.
so what could I be missing
I am trying to rework the dell to see if the 32-bit works there. Do you think it could be a amd vs. intel issue? here's my load procedure for centos 5
1. load centos with no extra applications, lots of standard included apps are deselected,like games, etc.
2. run this yum command as a preload:
yum -y install gcc gcc-c++ kernel-smp-devel kernel-devel bison openssl-devel
libtermcap-devel ncurses-devel doxygen curl-devel newt-devel
mlocate lynx tar wget nmap bzip2 mod_ssl crontabs vixie-cron
speex speex-devel unixODBC unixODBC-devel libtool-ltdl zlib-devel
libtool-ltdl-devel mysql-connector-odbc mysql mysql-devel
mysql-server php-mysql php-mbstring php-mcrypt flex screen
3. Untar and make zap, libpri, asterisk.
I don'tdo anything besides what is shown, this worked on the P4.
#1 rule about asterisk no
#1 rule about asterisk
no frame buffers...
no frame buffers...
no frame buffers...
I finally figured it out
The successful sequence:
I loaded CentOS 5.2 686 with my RAID drivers and it loaded a 2.6.18-92.el5-PAE-i686 kernel. I ran the yum install shown above. Then I did a full yum update, which updated the kernel to 5.3. Amazingly (and for the first time), the yum update didn't cause a kernel panic after the reboot, and it looks like the RAID stayed intact (when I tried to load 5.3 from distro I could never see the RAID). I found and used a command kernel-PAE-devel, which loaded a 2.6.18-128.7.1.el5-PAE-i686 in /usr/src/kernels/. I then symlinked my /usr/src/linux and usr/src/linux26 to that. Zaptel compiled and all on top, all good and running, when I do a service zaptel start it actially shows it running.
Now I'm off to restore my system!!
x86_64
I'm running x86_64 on CentOS 5.2 & 5.3 since more than a year. I used zaptel on the past, and dahdi now. the only secret you need to take care is when you compile both zaptel or dahdi, and then Libpri is that you point to the right directories.
By defautl all compilations put the libraries on on /var/lib, but what goes to /lib needs to be in /lib64.
Apart of that, everything runned smoth.
And, yes of course you need to have the full kernel sources on the system.
x86_64
How dow we take care of that?
is there an option in configure to achieve that?
or we have to replace every /lib to /lib64 in the configure script?
I am moving a production asterisk to a new server and need to compile zaptel and make it work, of course
Regards
By the way Im using Centos 5.3 and 2.6.18-164.6.1.el5
I also ran make install-udev before make config a few times, with no effect.