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? -- Florin Andrei http://florin.myip.org/
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! -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
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 http://florin.myip.org/
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 http://florin.myip.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mkspec.patch Type: text/x-patch Size: 1708 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20071022/62cde5ed/attachment-0004.bin>
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 http://florin.myip.org/
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. -- Florin Andrei http://florin.myip.org/