I like to tweak. I really really do. This should help you understand why I insist on running the Cooker version of Mandriva. BUT…due to certain structural changes in the kernel config (I assume) between the 2.6.18 and 2.6 19 versions, I have been unable to successfully take my vanilla (but customized) kernel past 220.127.116.11. Success means mostly everything works (I can sacrifice VMware Server, since I really only use Windows for Turbo Tax [see previous post if you’re really that interested]). The firewall, Xorg, networking, everything else, should work. I should mention now that every kernel I have run up to 18.104.22.168 has been heavily customized (by me) to strip out all the cruft I do not need. You know, token ring, ATM drivers, FDDI, etc. All gone. Took a while the first time, so thank God for “make oldconfig”. This worked right up until the 2.6.19 kernel, when I had lotsa problems.
Since 2.6.18 was running good enough, I just kept going with minor version patches up to 22.214.171.124. Attempts to go beyond 2.6.18.x ended badly, with me always crawling back to the “Old Faithful” kernel, regardless of which machine (mine, my son’s, or work) I tried it on. Something always failed to work as planned, with serious enough errors to be beyond my skill level to fix (which is not actually that hard, to be frank). Tonight, however, I resolved to upgrade beyond the 2.6.18 kernel, the easy way.
I could have simply looked at error logs, dmesg output, and (on the stable version) kept reconfiguring and recompiling until I got it right. Instead, I let Mandriva do the work for me by installing the Mandriva kernels via urpmi. I almost never use the GUI for installs anymore, since the command line is so much faster and simpler. I tried “urpmi kernel”, “urpmi 2.6.19”, “urpmi 2.6.20”, and “urpmi 2.6.21”, which listed all installable packages with that text in the names, until I found the kernel-linus- packages. Then I installed the 2.6.21-0.rc3.4mdv and matching source package, rebooted to the 2.6.21-0.rc3.4mdv kernel (“lilo -R 2.6.21-0.rc3.4mdv” and reboot), and quickly determined that the latest NVidia drivers would not install. I next used lynx to download the 2.6.20 kernel and the 2.6.21-rc4 patch, extracted the 2.6.20 tar.bz file into /usr/src, bunzipped the patch file, and patched the 2.6.20 kernel up to 2.6.21-rc4 (“patch -p1 < [patch file]). I also checked my /boot partition to compare sizes – my custom 126.96.36.199 kernel was about 1.3 MB – the new 2.6.21 kernel was 1.5 MB. Oh yeah – it is really important that the base kernel version (the “2.6.20” version) be used when patching to an RC version, so do not try this with 2.6.20.x, or attempts to patch will fail.
Anyway, after changing the soft link for Linux over to the new Linux source directory for 2.6.20 (“rm -f linux” and “ln -s linux-2.6.20 linux”), I cd’d into the linux directory, ran “make oldconfig”, “make && make modules && make modules_install && make install”, and waited. Once it finished (no errors), I rebooted on the new kernel, and all was well. It booted fine, and I was able to install the latest NVidia driver. I was unable to get VMWare Server (even the newest 1.0.2 version) to install, but this just means I won’t upgrade at work for a while. Everything else seems fine. I will try “make menuconfig” later on and dig through the kernel to see what cruft I can take out.
So basically, rather than troubleshoot this, I let Cooker fix the kernel issues I was having with my custom kernel, by giving me a fatter distro kernel config that I later used as a basis to install a new, non-custom vanilla kernel. This also kinda goes against my past post of upgrading vanilla kernels, but I probably would not have has so many problems if I had not tweaked my kernel as much as I did. Again, I’ll need to run through the new kernel and trim the fat, but at least I am on the newer version, which *should* make future upgrades go more smoothly, at least until big enough changes happen again <smirk>. The price of progress, I guess…