[CentOS] Re: Putting CentOS 5.2 kernel on CentOS 4.x

[William L. Maltby]

Please, take the time to intersperse your replies. Top-posting makes it
harder to follow.

On Fri, 2008-10-03 at 17:39 -0700, Fong Vang wrote:
> So you're saying that the CentOS 4.x system is married with the 2.6.9
> kernel?

No.

> Maybe the packaging of the kernel RPM is different between 4.x and
> 5.x, but why would a 5.x kernel not work on a 4.x system, especially
> considering you can always download the latest kernel from the kernel
> source tree and run that so this doesn't sound right.

I don't believe rpm packaging is an issue. As long as prerequisites are
satisfied, rpm would do its thing.

Anything is possible. And may even be easy. The CentOS wiki has a page
on making your own kernel. *Usually* this is done within the same major
branch, for good reasons. Often it is just to enable some feature which
is disabled by default by upstream. Within the same major kernel
version, this is often no problem as efforts have been made to avoid
breaking ABI by the glibc and kernel folks.

Expand your consideration to a system view. Kernel provides basic
functions and management. To use these, system calls are used. These
have required parameters. They must have the right attributes, order,
etc. Most of these interfaces are provided through a set of libraries,
glibc being the predominate one, that provide an Application Binary
Interface (ABI) made to match a major kernel version. This does
insulate, to some degree, the applications from changes in the
underlying kernel. Applications can make the system calls directly and,
thus, are not insulated if they do so. If if that is not done, there are
limits. If the kernel changes are too great, relative to the specific
version of glibc and other libraries, the binary interface may be broken
in certain areas.

If you upgrade the glibc (and any other needed libraries - might be only
a few, I don't know) to support the kernel, then the applications may
need to be recompiled to use the new libraries. And other libraries that
depend on glibc, and other apps/libs that depend on those, and other ...

None of this is certain. In C (and C++) which, IIRC, is the language
used, there are techniques that can allow for certain types of
mismatches. But this does take more code.

> 
> I just need the later kernel, not the new glibc which will break
> compatibility.

Like the other person said, give it a shot. But as he said, use a test
system.

Last, consider the following. System maintenance. As upgrades occur in
the kernel and/or libraries and applications, you may have a maintenance
nightmare. One very small change in any of the components may render
your system unreliable or even not runnable. You may have to maintain
many sources yourself. Even 1 source may be tough. Automatic updates may
not be at all feasible. You may miss, or be unable to install, critical
security updates or fixes without great effort.

Summary in "real world" terms: you can't stick the pistons, conn rods,
intake manifold, ... from a 1966 Pontiac GTO (389 c.i., tri-power, ...)
in a Ford 302 very easily. :-(

So, just proceed with caution, consider long-term impact and how smart
or dumb you might appear to those who matter later on.

If the later kernel is your *primary* factor, build (beg, borrow, steal)
a system around it.

> <snip>

-- 
Bill