Today I upgraded my current kernel (2.6.24) to the newest, 2.6.25 and also made some minor changes to the config-file. I added some new options, and removed a few I thought was unnecessary.
After the new kernel compiled successfully, I moved the image to /boot and configured lilo. Then, I did a quick reboot and everything worked fine, or so I thought.
I compiled the kernel while I was attending a rather boring lecture at school, and I didn’t have the opportunity to check how the whole system worked until I got home. When I finally got home, I had to relax a bit so I put on some music. To my surprise, Audacious returned an error saying it couldn’t access the sound-device. I then checked the rights on every file related to sound in /dev, and everything seemed to be in order. Then, I tried reconfiguring ALSA by running alsa-conf, but neither that seemed to do the trick.
My last resort before googling for an answer was checking the audio-tab under preferences in Audacious. Making sure that “Current output plug-in” was set to ALSA 1.3.5, I clicked the button “Output Plugin Preferences” and noticed that the current audio-device was set to “default”. I tried switching to one of the other fields in the combobox (Intel ICH6: xxx), and guess what. Audacious finally worked again.
Since I now was able to play audio without problems, I settled for using this workaround – at least until I tried playing a movie through MPlayer. When I attemped to watch a movie, I got the error-message “X11 error: BadAccess (attempt to access private resource denied)” slammed in my face. I also tried running gmplayer – which refused to start and returned the error-message “Fatal Error! – [ws] shared memory extension error.”. Now I realized that something was very wrong. Using my wits, I determined that the issue had to be with the newly compiled kernel. I ran a “make menuconfig” and tried to locate any misconfigurations.. ..although without results.
I was now out of ideas and went on to the last resort and googled the error-message outputted by gmplayer along with “kernel”. A few minutes and 4 webpages later, I found the solution to the problem.
While I was configuring the new kernel, I had disabled “System V IPC” (CONFIG_SYSVIPC), which is located under “General Setup”. I remember reading the help-message before I disabled this option and it didn’t look very important. It stated that some programs, like “dosemu” wouldn’t work unless this was turned on. Since I don’t use dosemu, but dosbox instead, I thought I wouldn’t be needing it and therefore left it out.
However, I was very wrong and from now on, I will always compile my new kernels where I’ll include CONFIG_SYSVIPC. And yes, when the new kernel was compiled yet again, I booted it and everything worked like it used to.