On 4/9/06, Neil Cherry <ncherry@xxxxxxxxxxx> 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
