I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out for?
Any advice is appreciated. A link to a decent howto would be awesome.
maillists0@gmail.com wrote:
I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out for?
So why not try RHEL v6 beta?
Any advice is appreciated. A link to a decent howto would be awesome.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, May 1, 2010 at 4:34 PM, Rob Kampen rkampen@kampensonline.comwrote:
maillists0@gmail.com wrote:
I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out for?
So why not try RHEL v6 beta?
Any advice is appreciated. A link to a decent howto would be awesome.
The box is about 1200 miles away and I figure I might as well give this a try before spending the money on remote hands. Plus my boss doesn't like the license stuff with Redhat.
On Sat, May 1, 2010 at 4:40 PM, maillists0@gmail.com wrote:
On Sat, May 1, 2010 at 4:34 PM, Rob Kampen rkampen@kampensonline.com wrote:
maillists0@gmail.com wrote:
I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out for?
So why not try RHEL v6 beta?
Any advice is appreciated. A link to a decent howto would be awesome.
The box is about 1200 miles away and I figure I might as well give this a try before spending the money on remote hands. Plus my boss doesn't like the license stuff with Redhat.
I hope you're planning on trying this on a local test machine or a VM specifically setup for this before trying it remotely. Also, make sure you have a backup plan, such as remote access to the console, and hopefully another machine with a PXE boot to be able to reinstall the OS or boot to a rescue disk.
on 5-1-2010 1:40 PM maillists0@gmail.com spake the following:
On Sat, May 1, 2010 at 4:34 PM, Rob Kampen <rkampen@kampensonline.com mailto:rkampen@kampensonline.com> wrote:
maillists0@gmail.com <mailto:maillists0@gmail.com> wrote: I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out for? So why not try RHEL v6 beta? Any advice is appreciated. A link to a decent howto would be awesome.The box is about 1200 miles away and I figure I might as well give this a try before spending the money on remote hands. Plus my boss doesn't like the license stuff with Redhat.
I don't like to experiment on production systems that are 12 FEET away, and you want to do this to one that is 1200 miles away? You are way braver than I am!
On Sat, May 1, 2010 at 1:28 PM, maillists0@gmail.com wrote:
I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out for?
Any advice is appreciated. A link to a decent howto would be awesome.
You did not tell us why you want to run 2.6.32 on CentOS 5.4. I assume you are aware of backporting and 2.6.18 is not the same as vanilla kernel 2.6.18.
Having said that, if you really, really need to run/build such a new kernel, I advice you read through this CentOS forum thread in its entirety:
https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_i...
(Note: custom kernels are not supported by CentOS)
Akemi
On Sat, May 1, 2010 at 4:37 PM, Akemi Yagi amyagi@gmail.com wrote:
On Sat, May 1, 2010 at 1:28 PM, maillists0@gmail.com wrote:
I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out
for?
Any advice is appreciated. A link to a decent howto would be awesome.
You did not tell us why you want to run 2.6.32 on CentOS 5.4. I assume you are aware of backporting and 2.6.18 is not the same as vanilla kernel 2.6.18.
Having said that, if you really, really need to run/build such a new kernel, I advice you read through this CentOS forum thread in its entirety:
https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_i...
Thanks, Akemi. I really want to try the fs-cache feature to make an nfs caching proxy. It would be a godsend.
I was wondering whether the standard "make oldconfig" would work when making a version jump this large. Are my drivers likely to break?
On Sat, May 01, 2010 at 04:44:49PM -0400, maillists0@gmail.com wrote:
I was wondering whether the standard "make oldconfig" would work when making a version jump this large. Are my drivers likely to break?
*All* bets are off with this. It's unsupported and for good reason. Redhat has, literally, *many hundreds* of patches in the kernels they ship that the vanilla kernel kits don't provide, it is entirely likely hardware support is different including drivers.
John
On Sat, May 1, 2010 at 4:51 PM, John R. Dennison jrd@gerdesas.com wrote:
On Sat, May 01, 2010 at 04:44:49PM -0400, maillists0@gmail.com wrote:
I was wondering whether the standard "make oldconfig" would work when
making
a version jump this large. Are my drivers likely to break?
*All* bets are off with this. It's unsupported and for good reason. Redhat has, literally, *many hundreds* of patches in the kernels they ship that the vanilla kernel kits don't provide, it is entirely likely hardware support is different including drivers.That's exactly what I was wondering about. That said, I'm willing to sort
through it all if I can just find the right docs, but I'm just inexperienced enough that I don't know where to start looking.
Redhat has a kernel src rpm available. Is that patched? If I started with the vanilla kernel, where might I find guidance on how to apply the Redhat patches? Is this a completely crazy idea?
maillists0@gmail.com wrote:
On Sat, May 1, 2010 at 4:51 PM, John R. Dennison <jrd@gerdesas.com mailto:jrd@gerdesas.com> wrote:
On Sat, May 01, 2010 at 04:44:49PM -0400, maillists0@gmail.com <mailto:maillists0@gmail.com> wrote: > > I was wondering whether the standard "make oldconfig" would work when making > a version jump this large. Are my drivers likely to break? *All* bets are off with this. It's unsupported and for good reason. Redhat has, literally, *many hundreds* of patches in the kernels they ship that the vanilla kernel kits don't provide, it is entirely likely hardware support is different including drivers.That's exactly what I was wondering about. That said, I'm willing to sort through it all if I can just find the right docs, but I'm just inexperienced enough that I don't know where to start looking.
Redhat has a kernel src rpm available. Is that patched? If I started with the vanilla kernel, where might I find guidance on how to apply the Redhat patches? Is this a completely crazy idea?
While I can't speak for specific features in the redhat kernel, I have taken the config file that comes with a CentOS kernel and applied it to a kernel.org kernel using make menuconfig. I then went quickly through the options added in the more recent kernel and selected reasonable values for them. The resulting kernel ran just fine, but, as I said I was not trying to use any new features added by redhat. Note, that you want to build the new kernel under the CentOS release that you'll be running it under. Perhaps you could apply a procedure similar to this using the RedHat 6 kernel instead of a kernel.org kernel (building with the CentOS 5.x or whatever config file and then changing the options that you want to change - you might have problems if you try to enable features not supported by older lib files).
Nataraj
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, May 1, 2010 at 1:56 PM, maillists0@gmail.com wrote:
That's exactly what I was wondering about. That said, I'm willing to sort through it all if I can just find the right docs, but I'm just inexperienced enough that I don't know where to start looking.
If this is your first time doing anything like this, it's a poor place to start. Building custom kernels is relatively easy if you're just adding a module or fixing a bug, but jumping 14 versions of the kernel to a functionally distant future from the more-than-a-year-old base for CentOS 5.4 is a big leap, especially if you've never done that before. You're asking to break the system.
Speaking from experience with experiments of this nature, I'd recommend against it.
mhr
On Sat, 1 May 2010, maillists0@gmail.com wrote:
On Sat, May 1, 2010 at 4:37 PM, Akemi Yagi amyagi@gmail.com wrote:
On Sat, May 1, 2010 at 1:28 PM, maillists0@gmail.com wrote:
I want to upgrade a 5.4 box with the 2.618 kernel to a shiny new 2.6.32 kernel. Anyone done it? Is it possible? Are there gotcha's to watch out
for?
Any advice is appreciated. A link to a decent howto would be awesome.
You did not tell us why you want to run 2.6.32 on CentOS 5.4. I assume you are aware of backporting and 2.6.18 is not the same as vanilla kernel 2.6.18.
Having said that, if you really, really need to run/build such a new kernel, I advice you read through this CentOS forum thread in its entirety:
https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_i...
Thanks, Akemi. I really want to try the fs-cache feature to make an nfs caching proxy. It would be a godsend.
I was wondering whether the standard "make oldconfig" would work when making a version jump this large. Are my drivers likely to break?
RHEL5 actually used to ship FS-Cache as part of their 2.6.18 kernel. You can find an interesting article on LWN about this:
http://lwn.net/Articles/312708/
It used to be a technology preview up to 5.2, but I think it disappeared in the release notes of 5.3. And there is a bugzilla entry on to why:
https://bugzilla.redhat.com/show_bug.cgi?id=481579
Since FS-Cache was not mainlined, I think Red Hat ditched the idea of making it a supported option for the remaining 5 years of RHEL5. I guess testing with RHEL6 beta and then moving to CentOS 6 eventually is the safest option for production use.
libtool, libudev, mcelog, nash,udev,usbutils and hal also have to be
updated to get the whole thing working...
That is exactly the kind of info I was looking for. Thanks.
dag, thanks for the article. I'm tempted to rebuild a 2.6.18 kernel without the patches that disable fs-cache. It's hard to tell if Redhat abandoned it because it was unstable or because it was too much trouble to maintain something they thought might never make the mainline kernel.
I also see now that even the 2.6.32 kernel has to be patched to allow export of an already mounted nfs share, which is what I'd hoped to do. This project is even more ambitious than I first thought.
A caching NFS proxy looks entirely doable with NFS4, fs-cache and cachefilesd, and I see on the web that others have thought of it but I haven't found an example of an actual implementation. Delegation and referrals seem perfect if the workload is mostly reads, and you'd even have a persistent cache. The question is why hasn't someone put it all together in a package or distribution? This would be highly useful for me, and I suspect a lot of other people would also use it.
maillists@gmail.com wrote:
dag, thanks for the article. I'm tempted to rebuild a 2.6.18 kernel
without
the patches that disable fs-cache. It's hard to tell if Redhat abandoned it because it was unstable or because it was too much trouble to maintain something they thought might never make the mainline kernel.
I believe the FS-Cache code wasn't removed from the RHEL 5.x kernels - it was just the fsc option that was disabled in the kernel mount options and also disabled in nfs-utils (mount.nfs) as well.
It would be quite easy to remove this kernel patch and rebuild a kernel (and rebuild nfs-utils, or use a version of mount.nfs from 5.2)- however, the FS-Cache code in these kernels is now quite old and very likely to be buggy - RedHat has not updated the kernel code to match the mainline kernels since 5.2
Personally, I would wait for CentOS 6 - but even then, FS-Cache is currently classed as a 'preview' technology in the RHEL 6.0 beta
James Pearson
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of James Pearson Sent: Sunday, May 02, 2010 5:54 PM To: CentOS mailing list Subject: Re: [CentOS] Upgrading to 2.6.32
maillists@gmail.com wrote:
dag, thanks for the article. I'm tempted to rebuild a 2.6.18 kernel
without
the patches that disable fs-cache. It's hard to tell if Redhat abandoned it because it was unstable or because it was too much trouble to maintain something they thought might never make the mainline kernel.
I believe the FS-Cache code wasn't removed from the RHEL 5.x kernels - it was just the fsc option that was disabled in the kernel mount options and also disabled in nfs-utils (mount.nfs) as well.
It would be quite easy to remove this kernel patch and rebuild a kernel (and rebuild nfs-utils, or use a version of mount.nfs from 5.2)- however, the FS-Cache code in these kernels is now quite old and very likely to be buggy - RedHat has not updated the kernel code to match the mainline kernels since 5.2
Personally, I would wait for CentOS 6 - but even then, FS-Cache is currently classed as a 'preview' technology in the RHEL 6.0 beta
James Pearson _______________________________________________
Thanks for the informative post; I was a bit puzzled at first after reading the previous postings regarding this topic as I have seen the FS-Cache: Loaded message every time I log in as a user whose home directory has been automounted.
-
Akemi Yagi -
Brian Mathis -
Dag Wieers -
Dan Burkland -
James Pearson -
John R. Dennison -
maillists0＠gmail.com -
MHR -
Nataraj -
Rob Kampen -
Scott Silva