26 Aug 2004
(updated 26 Aug 2004 at 15:34 UTC) »
Let me start by saying I'm a big fan of source based distros for a large number of reasons. The primary reason for this bias deals with the fact that getting any kind of new software installed on a binary distro can be a real bitch. Source or binary package - it doesn't matter, this problem is something unholy and can poison your soul.
I finally got Redhat9 working with linux-2.6.8-1. This effort took a week for a variety of reasons (mostly management related stuff) but, it works. So, I'm happy. We have a software requirement to use Redhat9 and since our hardware is new...things like old network drivers and power management code just didn't work well. Hence the desire to trouble about this new kernel on an unsupported
I'd also like to note that many of my friends would agree. I am a sick person. I like to do things like this just "because". I also have a remarkable ability to crash any software system on the planet within 3 minutes of sitting down to it. I'm reknown in some circles.
Since I had such a tough time getting this bizarre configuration working here's how I troubleshot the hell out of the problem (this effort required ninjary built up from years of binary-package and source based distro experience):
- Fresh Redhat9 install.
- RPM install of the 2.6.8-1 kernel
- Source installation of modules-init (making sure to `./configure --prefix=/` and `make moveold` prior to `make install`, running `./generate-modprobe /etc/modprobe.conf` at the conclusion of the build installation.
- Source installation of the 2.6.8-1 kernel.
- mkinitrd vmlinuz-188.8.131.52.img 2.6.8-1 && cp vmlinuz*.img /boot
- Update grub
- Reboot, make the sign-of-the-cross, and cross fingers.
Now for a review of what happened. B/c I've been a Gentoo user for the past 2 years, my brain has been subject to some un-binary-package-friendly ways of thinking.
The first step is obvious. For some reason the only way to get binary-package systems "cleanly" installed/updated usually requires a fresh reload. The db backend is unholy and hates it when you make major dependency alterations.
Second step, this got all the init.d and rc.d scripts patched for the 2.6 kernel on the Redhat9 machine I was working on. It also provided me a good testing ground for my next step.
Third step, do this with source. It's sexier. And when you reboot if you see "Q_MODULE" type stuff floating around. That means your modprobe, etc programs are in a bad path. And the kernel can't get modules loaded and stuff.
Fourth step, seems redundant, no? Well, let's just say I needed special tweeks for my platform. That and on my hardware, the rpm version of the kernel's acpi support (I suspect) kept shutting the machine off for a reason I've yet to determine (well, that's what the Magic 8 Ball told me
Next step, this was brutally important
. I've never-ever-ever had to use mkinitrd. Apparently, est muy importante
for Redhat9 initalization scripts and grub. (I use lilo at home). Do this. For the love of God and all things holy on this earth...do it.
The last two steps are trivial and require no explaination.
End rant. Back to Scout. It's *kinda* working. MFC ListView objects hate me.