Let's say I want to use a much newer kernel - even one from the future, such as the upcoming 2.6.24. :-) What would y'all smart folks do in this case, in order to avoid any possible nasty consequences? Would you import the config file from the original CentOS5 kernel into the new kernel, and let the kernel deal with the differences? I.e. have the old configuration as some sort of baseline that can be further tweaked. Or some other strategy?
on 10/4/2007 9:39 AM Florin Andrei spake the following:
Let's say I want to use a much newer kernel - even one from the future, such as the upcoming 2.6.24. :-) What would y'all smart folks do in this case, in order to avoid any possible nasty consequences? Would you import the config file from the original CentOS5 kernel into the new kernel, and let the kernel deal with the differences? I.e. have the old configuration as some sort of baseline that can be further tweaked. Or some other strategy?
I would recommend not using the latest and greatest kernel with an Enterprise distro. You have a good chance of breaking it. If you want new, use Fedora Core. If you want stable, use CentOS and don't poke the bear!
Scott Silva wrote:
I would recommend not using the latest and greatest kernel with an Enterprise distro. You have a good chance of breaking it. If you want new, use Fedora Core. If you want stable, use CentOS and don't poke the bear!
Honestly, all I need CentOS for is a reliable source of convenient package updates for the systems. Plus the fact that being a Red Hat clone makes it easier to find people with appropriate skills.
These systems will be minimal installs - even less than the default minimal that can be achieved via Anaconda, plus a couple custom packages. Think - home-made appliances, or sorts. There will be very, very few things running on these machines.
The problem with kernel 2.6.18 is that netfilter has the old (I mean, current) braindead conntrack that is loaded when NAT is used. Now, configure pktgen full blast over a gigabit link, small UDP packets, set it to generate random source IPs (DDoS simulation) and point it to a Linux router with conntrack loaded, and you'll see why I can't use the default kernel.
Apparently there will be improvements in that regard in 2.6.23, and I've heard that 2.6.24 will actually be able to do 1:1 NAT without conntrack.
On 10/4/07, Florin Andrei florin@andrei.myip.org wrote:
These systems will be minimal installs - even less than the default minimal that can be achieved via Anaconda, plus a couple custom packages. Think - home-made appliances, or sorts. There will be very, very few things running on these machines.
The problem with kernel 2.6.18 is that netfilter has the old (I mean, current) braindead conntrack that is loaded when NAT is used. Now, configure pktgen full blast over a gigabit link, small UDP packets, set it to generate random source IPs (DDoS simulation) and point it to a Linux router with conntrack loaded, and you'll see why I can't use the default kernel.
Apparently there will be improvements in that regard in 2.6.23, and I've heard that 2.6.24 will actually be able to do 1:1 NAT without conntrack. -- Florin Andrei
As pointed out earlier, whether or not a vanilla kernel runs with no issues would depend on what else is running on the system, and there are people who have been compiling and using a newer kernel for one reason or another. You can find one such example in this CentOS forum post by Lenard who has been helping those who need to compile newer kernels:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=10001&forum=3...
Akemi
Florin Andrei wrote:
Let's say I want to use a much newer kernel - even one from the future, such as the upcoming 2.6.24. :-) What would y'all smart folks do in this case, in order to avoid any possible nasty consequences? Would you import the config file from the original CentOS5 kernel into the new kernel, and let the kernel deal with the differences? I.e. have the old configuration as some sort of baseline that can be further tweaked. Or some other strategy?
Once you take the kernel off the reservation be warned that some packages in the repository may bork:
most likely: packages that have a kernel module (drbd, etc) moderate likelihood: low-level api packages (glibc etc) less likely: high-level user-space apps (apache etc)
Knowing the consequences of that, then what I might do is try to wrap my own kernel RPM spec file, remove all patches from current one so you have the bare spec. Keep the config files, but for new options you may get prompted during build, so afterwards move the BUILD\kernel... configs into the SOURCE so the next build won't prompt you.
This way when you install it you can remove it easily and everything is installed CentOS appropriate.
Make sense?
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
Florin Andrei wrote:
Let's say I want to use a much newer kernel - even one from the future, such as the upcoming 2.6.24. :-) What would y'all smart folks do in this case, in order to avoid any possible nasty consequences? Would you import the config file from the original CentOS5 kernel into the new kernel, and let the kernel deal with the differences? I.e. have the old configuration as some sort of baseline that can be further tweaked. Or some other strategy?
I recently had to build kernel 2.6.22 for one 4.5 box to use a specific IDE/SATA DMA controller. The 'make menuconfig' utility in the kernel.org packages will allow you to import a .config file from the CentOS kernel sources and use that as a starting point. I found that some modules did not get automatically included from the .config file, like some of the connection tracking stuff in netfilter. This might be from changed module names, etc. You should always review each menu in 'make menuconfig' and verify the right modules are activated for your needs.
I used the instructions on this page to build a kernel the 'traditional' way: http://www.howtoforge.com/kernel_compilation_centos_p2
The reality is that this process is a build, install, boot, check, repeat until comfortable situation. Check the dmesg and review files in /var/log to be sure your various services are happy with the new kernel. Most importantly, use the stock CentOS kernels unless there is something specific you need from a custom kernel.
That being said, the 2.6.22 kernel I built has been running fine for a while without issue.
Good luck!
Florin Andrei wrote:
Let's say I want to use a much newer kernel - even one from the future, such as the upcoming 2.6.24. :-) What would y'all smart folks do in this case, in order to avoid any possible nasty consequences? Would you import the config file from the original CentOS5 kernel into the new kernel, and let the kernel deal with the differences? I.e. have the old configuration as some sort of baseline that can be further tweaked. Or some other strategy?
To answer my own question, this looks like the correct method:
http://wiki.centos.org/HowTos/Custom_Kernel
Florin Andrei wrote:
Let's say I want to use a much newer kernel - even one from the future, such as the upcoming 2.6.24. :-) What would y'all smart folks do in this case, in order to avoid any possible nasty consequences? Would you import the config file from the original CentOS5 kernel into the new kernel, and let the kernel deal with the differences? I.e. have the old configuration as some sort of baseline that can be further tweaked. Or some other strategy?
I may post a real HOWTO, or add a page to the wiki, if I get a chance, but until then, here's what I did to obtain a newer kernel package as similar as possible to the default CentOS kernel.
Install CentOS in a new VMware instance, or on a clean system. Make sure to install the Development packages, and also the relevant kernel packages, especially kernel-devel and kernel-headers. kernel-doc doesn't hurt either. ;-) This will be your clean build environment.
Optionally, create a dedicated account for building packages as non-root. This is discussed in other HOWTOs. Login as that account.
Do a "yum update" to get all the recent patches and updates. Reboot.
Get the kernel source tarball with the desired kernel version. Unpack, do "make clean; make mrproper"
Get the CentOS kernel's config file (it's in /boot, e.g. /boot/config-2.6.18-8.1.14.el5) and save it into the kernel source tree as ".config" Then do a "make oldconfig".
Optionally, do a "make menuconfig" and tweak the kernel options even more. You may especially want to edit the CONFIG_LOCALVERSION field to reflect the fact that you're building a custom kernel. I prefer to make that field "COMPANYNAME.x" where x is the build number - start with x=1 for the first build, and bump it up as you're building new versions of the same kernel. This will enable painless upgrades if you decide to tweak the kernel options later.
Save the .config file (now modified by the make commands) in a safe place for future re-use.
Apply this patch to the scripts/package/mkspec file (careful, at least one line is wrapped by the Gmane mail archive, so unwrap manually):
http://thread.gmane.org/gmane.linux.kernel/593172
Or just use the patch file attached to this message if the mail archive doesn't work for you. Either way, the command to apply the patch is the same - from within the kernel source tree, run:
patch -p1 < mkspec.patch
Do "make rpm"
You will obtain a kernel rpm package that is similar in kernel features to the original CentOS kernel. Also, the package will do the right things (modify grub.conf, build initrd) when installed or uninstalled - that's what my patch to mkspec does.
Install with "rpm -i". Do not install with "rpm -U" (but you should know that already).
You may also want to upgrade packages such as iproute and iptables if you're using fancy features of very recent kernels. The actual versions to upgrade to depend on what you're doing. This upgrade may not be needed in "boring" scenarios.
Works For Me (TM) on CentOS 5 x86_64 with kernel 2.6.23.1
Florin Andrei wrote:
Apply this patch to the scripts/package/mkspec file (careful, at least one line is wrapped by the Gmane mail archive, so unwrap manually):
http://thread.gmane.org/gmane.linux.kernel/593172
Or just use the patch file attached to this message if the mail archive doesn't work for you. Either way, the command to apply the patch is the same - from within the kernel source tree, run:
patch -p1 < mkspec.patch
Do "make rpm"
Forgot to mention - for that patch to work, before running "make rpm" you have to execute "export RPM_RH5_STYLE=true", otherwise the features in the mkspec patch are not activated.
Florin Andrei wrote:
Optionally, do a "make menuconfig" and tweak the kernel options even more. You may especially want to edit the CONFIG_LOCALVERSION field to reflect the fact that you're building a custom kernel. I prefer to make that field "COMPANYNAME.x" where x is the build number - start with x=1 for the first build, and bump it up as you're building new versions of the same kernel. This will enable painless upgrades if you decide to tweak the kernel options later.
This is actually mandatory. Depending on the kernel version you're upgrading to, sometimes important kernel modules (SATA, NAT, etc.) will not be imported automatically from the original kernel config. So take some time and go through the configuration and make sure everything you need is still there.
-
Akemi Yagi -
Florin Andrei -
Jim Thario -
Ross S. W. Walker -
Scott Silva