Posted by: Anonymous Coward
on April 06, 2006 05:20 AM
So, I'm running yet another version of Asterisk@Home. It's a prepackaged Asterisk IP PBX server running on CentOS4.3. It had taken me nearly a day to get everything configured just the way I wanted for my home office and the server had been running for 99 days without any problems. That's great!
My desktop machine, SuSE 9.3 was on its second or third kernel update since I had installed the Asterisk@Home server so, I knew that there were kernel updates out there. I was feeling a bit guilty about not applying security patches to the Asterisk server for 99 days so, I decided to spend a few minutes updating it. Big mistake!
I log into the Asterisk@Home box and run <tt>yum update</tt> and it nicely downloads and installs all of the updates for my system, including a new kernel.
Now, I've been through this before. Asterisk uses a kernel module driver called zaptel for the POTS interface card, which is basically just a cheap modem. This driver module, like so many other Linux drivers, must be compiled for the specific version of the kernel that is being booted on the system. Knowing this, the Asterisk@Home developer conveniently includes a script that, though executed manually, recompiles and installs the zaptel kernel module after you update your kernel. I've updated the kernel on this system before and the script works so, on with the update.
After my <tt>yum update</tt> has finished, I reboot to load the new kernel and, as expected, the zaptel driver fails to load. No sweat, I think. I run the <tt>rebuild_zaptel</tt> script and the system grinds through the compile script for a few minutes before terminating abnormally with errors. It's complaining about references in the <tt>zaptel.c</tt> source file. That can't be right so, I rerun the recompile but, it still errors out. Oof! Still undeterred, I proceed to look through the <tt>zaptel.c</tt> file to see if there is anything that my small amount of C knowledge can figure out and fix.
After a while with no luck, logic starts to take over. This source file and compile script have worked several times before. The thing that has changed is the kernel and its source code. Well, I might be able to pull off a <tt>Hello World</tt> C program but, I'm no kernel hacker so, it's time for another plan as my phones have been out of commission for nearly an hour.
The obvious choice is to drop back to the old kernel. A quick reboot and I select the old kernel from the grub menu that Red Hat/CentOS has thoughtfully placed there for just such emergencies. I thought that it would boot right up to where I was before and my phones would work again. Silly me!
The system boots but fails to load the zaptel driver for some gobbledy-goop reason. That's because the previously failed half compile deleted some things and recompiled others, none of them successfully. So, I again run <tt>rebuild_zaptel</tt> to recompile the zaptel module for the older kernel that I am back to running again. Success! The driver compiles without a hitch and I reboot, expecting a running system but, I instead get an error about unable to find or access<nobr> <wbr></nobr>/dev/zap. Doh!!!
The phones have been down for over an hour now, I can't get the system to boot properly, I no longer have a clue what the problem is and my sphincter is starting to ache due to the tension. In an act of desperation, I decide to reconfigure the zaptel/modem thinking that perhaps its configuration was hosed by the botched recompile from earlier. It's been 99 days since last I had to configure a zaptel/modem card and my memory isn't photographic so, I was really greatful to find the <tt>genzaptelconf</tt> script from Asterisk@Home that automatically configures the card for you, provided you know to manually execute it in the first place. When it completes I <tt>modprobe</tt> the zaptel driver and it sees the card so, fingers crossed, I reboot again.
An hour and a half after the first reboot, my system finally comes up and the phones come to life. I'm elated and relieved. But, wait. I'm still running a kernel with known security bugs, what to do? Well, tough tomatoes! I need my phones to work and I don't have the knowledge/patience to fix whatever is wrong in the kernel source, or even the zaptel source that the system is blaming, seemingly incorrectly. It'll have to do without any further updates!
Learn about Linux
Download Linux
Get Linux help
Why I Hate Linux
Posted by: Anonymous Coward on April 06, 2006 05:20 AMMy desktop machine, SuSE 9.3 was on its second or third kernel update since I had installed the Asterisk@Home server so, I knew that there were kernel updates out there. I was feeling a bit guilty about not applying security patches to the Asterisk server for 99 days so, I decided to spend a few minutes updating it. Big mistake!
I log into the Asterisk@Home box and run <tt>yum update</tt> and it nicely downloads and installs all of the updates for my system, including a new kernel.
Now, I've been through this before. Asterisk uses a kernel module driver called zaptel for the POTS interface card, which is basically just a cheap modem. This driver module, like so many other Linux drivers, must be compiled for the specific version of the kernel that is being booted on the system. Knowing this, the Asterisk@Home developer conveniently includes a script that, though executed manually, recompiles and installs the zaptel kernel module after you update your kernel. I've updated the kernel on this system before and the script works so, on with the update.
After my <tt>yum update</tt> has finished, I reboot to load the new kernel and, as expected, the zaptel driver fails to load. No sweat, I think. I run the <tt>rebuild_zaptel</tt> script and the system grinds through the compile script for a few minutes before terminating abnormally with errors. It's complaining about references in the <tt>zaptel.c</tt> source file. That can't be right so, I rerun the recompile but, it still errors out. Oof! Still undeterred, I proceed to look through the <tt>zaptel.c</tt> file to see if there is anything that my small amount of C knowledge can figure out and fix.
After a while with no luck, logic starts to take over. This source file and compile script have worked several times before. The thing that has changed is the kernel and its source code. Well, I might be able to pull off a <tt>Hello World</tt> C program but, I'm no kernel hacker so, it's time for another plan as my phones have been out of commission for nearly an hour.
The obvious choice is to drop back to the old kernel. A quick reboot and I select the old kernel from the grub menu that Red Hat/CentOS has thoughtfully placed there for just such emergencies. I thought that it would boot right up to where I was before and my phones would work again. Silly me!
The system boots but fails to load the zaptel driver for some gobbledy-goop reason. That's because the previously failed half compile deleted some things and recompiled others, none of them successfully. So, I again run <tt>rebuild_zaptel</tt> to recompile the zaptel module for the older kernel that I am back to running again. Success! The driver compiles without a hitch and I reboot, expecting a running system but, I instead get an error about unable to find or access<nobr> <wbr></nobr>/dev/zap. Doh!!!
The phones have been down for over an hour now, I can't get the system to boot properly, I no longer have a clue what the problem is and my sphincter is starting to ache due to the tension. In an act of desperation, I decide to reconfigure the zaptel/modem thinking that perhaps its configuration was hosed by the botched recompile from earlier. It's been 99 days since last I had to configure a zaptel/modem card and my memory isn't photographic so, I was really greatful to find the <tt>genzaptelconf</tt> script from Asterisk@Home that automatically configures the card for you, provided you know to manually execute it in the first place. When it completes I <tt>modprobe</tt> the zaptel driver and it sees the card so, fingers crossed, I reboot again.
An hour and a half after the first reboot, my system finally comes up and the phones come to life. I'm elated and relieved. But, wait. I'm still running a kernel with known security bugs, what to do? Well, tough tomatoes! I need my phones to work and I don't have the knowledge/patience to fix whatever is wrong in the kernel source, or even the zaptel source that the system is blaming, seemingly incorrectly. It'll have to do without any further updates!
That's why I hate Linux.
#