The other day I decided to drastically reconfigure my home network.  I want to conduct some experiments with Kernel-based Virtual Machines and needed a stable host platform.  That naturally meant that Windows wasn’t an option.  I ultimately settled on CentOS 6.2 and redeployed my old gaming rig into service.  Some specs:

• Asus Maximus IV Extreme Z motherboard
• Intel Core-i7 2600k processor
• 16 GB of Corsair memory
• Sapphire Radeon HD 7970 OC graphics card
• SoundBlaster Recon3D sound card
• a variety of OCZ/Kingston SSDs

Now, based on previous experiences with various flavours of Linux, I knew that resolving hardware incompatibilities would be a pain.  Many manufacturers simply don’t make drivers for anything except Windows.  I was not expecting a stable system with a stock standard CentOS 6.2 install and, sure enough, I didn’t get it.

After selecting the Desktop package bundle and rebooting, I got a kernel-panic on boot.  The screen was full of errors, but none really helpful.  No way to scroll up either.  Resetting the machine allowed it to boot the second time around.

Since the file system was not yet mounted, none of the boot-time kernel panic messages were preserved and visible via dmesg.  I don’t have any serial ports on my machine so viewing via an external console was not an option.  Recompiling the kernel to direct syslog to a different machine was, well, a lot of mucking about that I didn’t really want to waste time on.  So… what to do?

In these sorts of situations in the past, simplifying the system has always helped narrow down the problem, so I figured I’d just do that.

The sound card caused me minor problems in Windows, and would be of no use on a server anyway, so I figured I’d get rid of it first.  Remove the CreativeLabs Recon3D, reinstall CentOS from scratch, reboot, panic.  Hmmm…

This time the visible error messages were different and had an IO/memory feel to them.  The Corsair memory had never caused a problem before, but I reseated all the sticks and memtested them just to make sure.  No problems there.  Let’s try the drives next.

My multi-boot setup is rather complex, and I spent the next few hours dealing with Windows 7’s utterly retarded desire to stick its damned boot loader on a different partition than the target of the OS install.  So incredibly stupid.  (However, since Microsoft obviously has no clue or inclination to do it the right way, further venting on the matter won’t help.)  On with the show.

Having (dis)connected more SATA cables than I care to count, and repaired/restored the Windows boot loader more times than I can remember, I finally had a disk/partitioning scheme which worked nicely and had CentOS targeted for one of the SSDs.  Reinstall CentOS from scratch, reboot, no panic.  A bunch of errors though.  Progress!

After lots of boot testing, I discovered that roughly one boot in four would still get a kernel panic, but the messages were now easy to see and had something to do with hda-codec.  Google ultimately leads me to the realisation that since I have my Sapphire Radeon HD 7970 OC graphics card linked to a 27″ iMac (acting as a dual-system display) via a Mini DisplayPort cable, the tunnelled HDMI signal was causing the probe to barf.  Yes, what is considered by most to be video hardware was causing an audio problem.  What joy.

Since I didn’t actually want to change my display setup (and bring in a dedicated display just for CentOS) I finally yielded and went to a third party repository and used yum to install the ALSA driver package.  (My goal is to keep the host OS as vanilla as possible, thus minimising 3rd party package installs is important.)  Bingo!  That did the trick.

The CentOS 6.2 system now installs cleanly and boots without any errors at all onto:

• Asus Maximus IV Extreme Z motherboard
• Intel Core-i7 2600k processor
• 16 GB of Corsair memory
• Sapphire Radeon HD 7970 OC graphics card
• Kingston SSD

Dozens of reboots later and no more kernel panics.  No errors of any kind, in fact.

Whilst one can never be 100% sure, I am confident that the system I have now will (re)boot reliably the vast majority of the time, and that’s good enough for me to disconnect it from keyboard, mouse and video and administer it remotely from now on.

Mission accomplished.

PS:  Astute readers will note that leaving a 7970 graphics card on a headless server is a bit of a waste.  Fear not, the 2048 stream processors will be kept busy with OpenCL work (appropriately enough, fluid dynamics).