[PlanetCCRMA] Kernels and Planet

[Fernando Pablo Lopez-Lezcano]

> bummer.
> 
> Can anyone tell me what I need to fix this? acpi code, presumably, but 
> since it returned much the same response for the previous 2.4.20 planet 
> kernel, I wonder why the acpi code is left out or whatever...is the code 
> some sort of planet secret or something? :-) Unfortunately it means I 
> won't use the planet kernel, and looks like I'll just use ck instead.

The kernel has to be (can be) rebuilt by installing the source rpm for
the kernel (which is not the same thing as the kernel source binary rpm
- I know, very confusing). 

Do an "rpm -q -a | grep ^kernel", if you see a kernel-source rpm
installed with the same version number as the kernel you are running
then that is just all the kernel source to rebuild additional modules
for the existing kernel, not the kernel source to rebuild the kernel
itself (It may be possible to do that but I have never tried). 

You have to download and install the .src.rpm for the kernel you want,
that will put things in /usr/src/redhat/*, all source files and patches
in the SOURCES subdir and the spec file for the kernel in the SPECS
subdirectory. Using the spec file you can rebuild the kernel from
scratch. It is more difficult if you want to change things, you will
have to learn to patch the spec file so that it does what you want. 

You could also create a source tree of the kernel ready to be built (ie:
with all the patches applied) by doing an "rpmbuild -bp spec_file_name",
you will find the tree in the BUILD subdir (of /usr/src/redhat). I don't
normally do this as I exclusively use rpms, so I can't really help. 

> This is much the same as the response from attepting to compile an RH9 
> kernel from source, if I recall. just replace acpi with devfs. 
> So....since neither redhat nor the planet kernels seem to be fixing 
> these between point releases, what should I do to make them compile? I 
> can navigate C code, but am not any kind of adept at programming it. For 
> now I'll presume it's one of those "we're teaching you and you'll thank 
> us for it" type gotchas. if you know what I mean :-)
> 
> Obviously they can be compiled, or there wouldn't be a binary release! 
> But then the binary release is 2.4.21-1.ll.caps or something, so what's 
> the difference between the binary and source, and why is there no 
> kernel-source to match? Certainly when using the previous 2.4.20 planet 
> kernel, for which the binary/source versions matched exactly, according 
> to the docs, the source would allow me to compile modules, but they 
> would be totally unuseable, and invariably have unresolved symbols.

Which kernel and which extra modules? That normally means that the
kernel source (the kernel-source-KERNEL_VERSION.i386.rpm package) that
the module build process is trying to use does not match the kernel that
is the target. There can be many reasons for that to happen. If they
match correctly then there are (should?) not be mismatches. 

> In a nutshell, this is why I'm using RH8 kernels for servers and ck for 
> workstations, as I've found I have fewest issues if I compile 
> everything; kernel, standard and extra modules from source...
> 
> Not meaning to whinge or anything...apart from the kernel, planet would 
> have to be the best solution for audio/media I've yet seen, and I'm sure 
> the kernel would be great....if I could compile it...I guess a lot of
> end users don't need to but I do.

The way to rebuild would be:
 - install the .src.rpm (it is linked from the web pages)
 - cd /usr/src/redhat/SPECS
 - rpmbuild -ba kernel-2.4.20-1.ll.acpi.spec
and you will get the i386 kernel
 - rpmbuild -ba --target i686 kernel-2.4.20-1.ll.acpi.spec
and you get the i686 kernels

If you want to go the rpm way you can modify the spec file to add
patches to the kernel (in addition to the ones I have), but the details
are beyond this initial email...

-- Fernando