Kernel build tree -- how to trim down

[Mostafa Afgani]

On 4/9/06, Neil Cherry <ncherry at comcast.net> wrote:

> I haven't had a chance to look at the link yet but if you only
> need to rebuild the modules you only need the Kernel development
> package, if you need to turn on/off other features you need the
> Kernel source (such as with NDISWrapper and the 4K -> 8K stack
> change). One other thing to note, we're used to seeing the
> kernel version (uname -r) look like this:

IMHO the steps outlined by Paul (link in earler post) are much easier
to follow -- if you're writing a book -- you might want to have a
look. On my first attempt at a rebuild, I had already followed roughly
what you suggested. But this has the tendency of generating a RPM that
is labeled 2.6.151.2054_FC5 instead of 2.6.15-1.2054_FC5 -- I have no
clue why the "-" gets dropped somewhere along the way. Funny thing is,
the kernel still reports (uname -r) 2.6.15-1.2054_FC5 -- it's just the
rpm names (both the filename & rpmdb name) get screwed.

I really wish I didn't have to do all this rebuilding -- I have a wifi
card with the rt2500 chipset. But the legacy driver (inherited from
Ralink) does not work on SMP enabled kernels. There is a new unified
driver in development but it still has too many problems. Since FC
devs decided that there will be no UP kernels for AMD64 archs, I'm
stuck with rebuilding -- just to remove that stupid SMP flag. This in
turn means that I can no longer just get my nVidia / ntfs / lirc
kernel modules as prepackaged rpms. I tried to rebuild the nVidia kmod
from Livna but that apparently requires kernel-kdump-devel -- I didn't
feel like wasting another 30 minutes rebuilding with kdump enabled in
the spec file so I just went and grabbed the driver from nVidia
instead. The only good thing about the rebuild was that I got to turn
on the NTFS flag and not have to deal with yet another module to
rebuild.

Sorry if it seems like I'm ranting here but what can I say -- I'm
upset, I'm very very upset.

-M