The Surprises Never End...

I've finally got the old hardware setup working with MANN, so the web site will continue to run until the replacement motherboard and CPU come in late next week. I'll post more info about what actually happened (for those of you who are interested in such things), but right now I have a bunch of non-computer related things I need to take care of. Note: Many thanks to David Decker, Jerry Vrooman, and Anonymous who made donations to help defray the cost of the hardware failure.Okay, so here's the story for all you unix/linux geeks out there who want to know why this took so long... :)



After discovering that my motherboard and CPU bit the dust (apparently from heat damage), I figured it would be a simple procedure to use an older CPU/motherboard combo I had laying around (which is going to be used as part of a father's day gift for my dad - keep it quiet!) for a week until the replacement parts come in.



Well, the burned-out system was an AMD Athlon (K7) architecture and had a kernel optimized for the K7, meaning that it tries to do things that only the K7 and newer processors can do. The temporary system is an AMD K6 (no, I don't support Intel) which can not handle many of the K7 instructions. So, I knew going into this that I needed to boot the system with a different kernel.



This is where the surprises started. By using a rescue disk, it was easy enough to boot using a new kernel, but the system would immediately hang after loading the kernel. After doing some usenet searches, I found that I was using a buggy kernel version. I met with more success using a different version, which started detecting the hardware on startup but hung just before init (the mother of all processes in Unix) started. I was stumped at that point, and wasted a lot of time trying different kernels and initrd versions.



Eventually, I posted my problem to a local linux user group mailing list and announced it on the MANN downtime page, and was fortunate enough that David Hill read about it. He pointed me to a usenet post reminding me that recent releases of Redhat come with an optimized glibc library, and that I was likely using a glibc version that was optimized for the K7. Thus there was no way I could boot the system unless I replaced all of glibc by hand (not a fun possibility) or stick my hard drive into another K7 machine and then boot it up fine and replace the RPMs with pre-K7 versions. I was lazy, had some machines at work that would do the trick, and opted for the latter choice. I was then able to stick the disk back in the server and everything came up fine. In the process I also read a ton of documentation about bootloaders and the unix boot process. So it wasn't a total waste of time.



It was, however, a waste of more than $200 that I had to shell out to get replacement parts (including a more reputable CPU heatsink and fan). I really don't feel comfortable openly asking for money, but donations at this time would be appreciated more than ever.



And for all you sysadmins out there, beware of architecture-optimized software packages (especially the main system libraries)! It's a good idea in many ways, but it can have consequences in hardware emergencies like this.

NOTICE: This story was migrated from the old software that used to run Mensactivism.org. Unfortunately, user comments did not get included in the migration. However, you may view a copy of the original story, with comments, at the following link:

http://news.mensactivism.org/articles/02/05/25/1842224.shtml