Has anyone tried to install a CentOS 5.x kernel on a CentOS 4.x system? Is this doable? I"m aware of the dependencies but I'm curious if anyone has done this successfully.
Basically, we have a few hundred 4.x systems that cannot be upgraded to 5.x, yet, but we do need the kernel update to fix the XFS problem as described here: http://bugs.centos.org/view.php?id=3125
on 10-3-2008 2:48 PM Fong Vang spake the following:
Has anyone tried to install a CentOS 5.x kernel on a CentOS 4.x system? Is this doable? I"m aware of the dependencies but I'm curious if anyone has done this successfully.
Basically, we have a few hundred 4.x systems that cannot be upgraded to 5.x, yet, but we do need the kernel update to fix the XFS problem as described here: http://bugs.centos.org/view.php?id=3125
You would be on your own with that! Do you have a non-critical system you can test on? You would probably need to get the source rpm and build it on a 4.x devel system.
On Fri, 2008-10-03 at 16:21 -0700, Scott Silva wrote:
on 10-3-2008 2:48 PM Fong Vang spake the following:
Has anyone tried to install a CentOS 5.x kernel on a CentOS 4.x system? Is this doable? I"m aware of the dependencies but I'm curious if anyone has done this successfully.
Basically, we have a few hundred 4.x systems that cannot be upgraded to 5.x, yet, but we do need the kernel update to fix the XFS problem as described here: http://bugs.centos.org/view.php?id=3125
You would be on your own with that! Do you have a non-critical system you can test on? You would probably need to get the source rpm and build it on a 4.x devel system.
Hmmm... Reaching through the half-heimers-fogged brain...
ISTR that the critical item is the APIs (binary compat) provided by glibc. If so, the glibc-2.5-24.i686 on 5.2 and the 2.3.4-2.41 are probably different enough that binary compatibility would be broken.
Further, compiling the recent kernel on 4.x might be also difficult because the source compatibility might be broken (although not certain) due to parameter changes introduced in the newer kernel version.
But, that's a whole bunch of "ifs" that may be worth investigating, depending on available time, resources and time constraints.
If one does get a clean compile and no apps break, very fortunate. If the source must be changed, be sure to maintain diffs that can be applied when new versions with critical fixes (like security) appear.
Overall, my personal bias would be to avoid the whole scenario.
<snip sig stuff>
If any of my above is FUD, please forgive. It's hard to recall so much from so long ago.
So you're saying that the CentOS 4.x system is married with the 2.6.9 kernel? 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 just need the later kernel, not the new glibc which will break compatibility.
On Fri, Oct 3, 2008 at 4:55 PM, William L. Maltby CentOS4Bill@triad.rr.comwrote:
On Fri, 2008-10-03 at 16:21 -0700, Scott Silva wrote:
on 10-3-2008 2:48 PM Fong Vang spake the following:
Has anyone tried to install a CentOS 5.x kernel on a CentOS 4.x system? Is this doable? I"m aware of the dependencies but I'm curious if
anyone
has done this successfully.
Basically, we have a few hundred 4.x systems that cannot be upgraded to 5.x, yet, but we do need the kernel update to fix the XFS problem as described here: http://bugs.centos.org/view.php?id=3125
You would be on your own with that! Do you have a non-critical system you
can
test on? You would probably need to get the source rpm and build it on a
4.x
devel system.
Hmmm... Reaching through the half-heimers-fogged brain...
ISTR that the critical item is the APIs (binary compat) provided by glibc. If so, the glibc-2.5-24.i686 on 5.2 and the 2.3.4-2.41 are probably different enough that binary compatibility would be broken.
Further, compiling the recent kernel on 4.x might be also difficult because the source compatibility might be broken (although not certain) due to parameter changes introduced in the newer kernel version.
But, that's a whole bunch of "ifs" that may be worth investigating, depending on available time, resources and time constraints.
If one does get a clean compile and no apps break, very fortunate. If the source must be changed, be sure to maintain diffs that can be applied when new versions with critical fixes (like security) appear.
Overall, my personal bias would be to avoid the whole scenario.
<snip sig stuff>
If any of my above is FUD, please forgive. It's hard to recall so much from so long ago.
-- Bill
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, Oct 3, 2008 at 5:39 PM, Fong Vang sudoyang@gmail.com wrote:
So you're saying that the CentOS 4.x system is married with the 2.6.9 kernel? 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.
If system call interfaces have changed, you *can't* always download and run the latest kernel from the kernel source tree. Sometimes programs that make system calls have to be recompiled along with the kernel. I haven't paid attention to whether there was any such change introduced frm 2.6.9 to 2.6.18; I'd sort of expect a bigger change in the version number if so.
Aside from the binary compatibility issue. though, occasionally things like the layout of /proc and /dev change in incompatible ways. The introduction of udev between CentOS 3 and 4 makes it seriously problematic to run a CentOS 4 or 5 kernel on a CentOS 3 system, for example. You may have to install more than just the kernel.
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>
-
Bart Schaefer -
Fong Vang -
Scott Silva -
William L. Maltby