Once, I was installing some kernel patches & something went wrong on a live server where we had hundreds of clients. Only one kernel was there in the system. So, the server was down for some time, and using a live CD, we got the system up & running & did the further repairing work.

Now my question: Is it a good idea to have a 2 versions of the kernel, so that if the kernel is corrupted we can always reboot with another available kernel? Please let me know.

Also, is it possible to have 2 versions of the same kernel? So that I can choose the another kernel when there is kernel corruption?

My Server Details:
CentOS release 6.5 (Final)

How can I have the same copy of this kernel, so that when my kernel corrupts, I can start the the backup kernel?

  • 4
    It seems to me that you have answered your own question. There is no downside to having multiple kernels, as long as you know they work with your system, and it can occasionally be useful if you run into problems with a particular kernel for some reason. Jan 13, 2015 at 11:44
  • Thanks, May be i didn't ask the qns correctly. How can I have the same copy of this kernel, So that when my kernel corrupted, I can start the backup kernel ?
    – Mani
    Jan 13, 2015 at 12:00
  • 2
    Sure you can have the identical kernel. The kernel is just a file on the disk. You could copy your existing kernel with a slightly different name. Jan 13, 2015 at 15:41
  • On one of the servers I inherited, it had 16 boot entries for 8 different kernels on it... You know, until I cleaned it up Jan 13, 2015 at 17:20
  • I usually keep the previous kernel in case something goes wrong.
    – Joshua
    Jan 13, 2015 at 18:01

2 Answers 2


Both RedHat and Debian-based distribution keep several versions of Kernel when you install a new one using yum or apt-get by default. That is considered a good practice and is done exactly for the case you describe: if something goes wrong with the latest kernel you can always reboot and in GRUB choose to boot using one of the previous kernels.

In RedHat distros you control number of the kernels to keep in /etc/yum.conf with installonly_limit setting. On my fresh CentOS 7 install it defaults to 5.

Also if on RedHat you're installing new kernel from RPM package you should use rpm -ivh, not rpm -Uvh: the former will keep the older kernel in place while the later will replace it.

Debian keeps old kernels but don't automatically removes them. If you need to free up your boot partition you have to remove old kernels manually (remember to leave at least one of the previous kerneles). To list all kernel-installing and kernel-headers packages use dpkg -l | egrep "linux-(im|he)".

Answering your question -- Also, Is it possible to have a 2 version of the same kernel ? -- Yes, it is possible. I can't check it on CentOS 6.5 right now, but on CentOS 7 I was able to yield the desired result by just duplicating kernel-related files of /boot directory and rebuilding the grub menu:

cd /boot

# Duplicate kernel files; 
# "3.10.0-123.el7" is a substring in the name of the current kernel
ls -1 | grep "3.10.0-123.el7" | { while read i; \
    do cp $i $(echo $i | sed 's/el7/el7.backup/'); done; }

# Backup the grub configuration, just in case
cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.backup

# Rebuild grub configuration
grub2-mkconfig -o /boot/grub2/grub.cfg

# At this point you can reboot and see that a new kernel is available 
# for you to choose in GRUB menu
  • thanks, I am working on it. But in CentOS 6.5, there is no "grub2-mkconfig". do you know, how to do this in centos 6.5, i think grub2 is only available in Centos 7. I am Googling now, if i find a soln, will update here.
    – Mani
    Jan 13, 2015 at 14:13
  • I modified those lines to suit Centos 6.5 as below and got stuck with how to update the grub.conf. ls -1 | grep "2.6.32-431.el6" | { while read i; \ do cp $i $(echo $i | sed 's/el6/el6.backup/'); done; } cp /boot/grub/grub.conf cp /boot/grub/grub.conf.backup
    – Mani
    Jan 13, 2015 at 14:27
  • thanks a lot!!! It worked and I modified like this ls -1 | grep "2.6.32-431.el6" | { while read i; \ do cp $i $(echo $i | sed 's/el6/el6.backup/'); done; } cp /boot/grub/grub.conf cp /boot/grub/grub.conf.backup and I edited the grup.conf manually. You can keep the UUID same, If you are going to copy in the same disk and partition.
    – Mani
    Jan 13, 2015 at 14:54

Yes, it is possible and I would say even advisable. You just need to set up the boot process to offer you the alternative. Typically this is done in the boot loader configuration - usually you can just duplicate the entry that is there and change kernel image filename and boot menu entry label.

On a production server this usually isn't a problem, but whenever you upgrade kernel it is a good idea to have a backup present. Some Linux distributions offer rollback (usually backed by file system snapshotting capabilities) on package updates to make the process as painless as possible, but even in those cases I would tend to keep a backup ready.

As for having several copies of the same kernel - even that would make sense, but as @goldilocks points out in the comment below, if your kernel gets corrupted you should think about replacing the hardware. On the other hand putting the duplicate on a different physical HDD might save you some troubles. But keep in mind, that the kernel image file is only ever used during boot.

  • I have modified the qns, Please let me know, How to have a backup kernel ? (preferably the same version)
    – Mani
    Jan 13, 2015 at 12:01
  • 3
    You shouldn't have to do anything, they're already there -- but in different versions. There's no point in having two the same version unless you compiled one of them yourself, otherwise they are just identical copies. The issue of "corruption" is sort of bogus -- by that logic you would need two identical copies of the entire system in case the bash binary were corrupted, the libc were corrupted, etc. all of which will render the system useless. These files shouldn't be getting "corrupted". If they are, replace your hardware.
    – goldilocks
    Jan 13, 2015 at 12:19
  • 1
    @goldilocks Or replace your sysadmin, depending on where the fault was. Jan 13, 2015 at 16:29
  • @goldilocks see updated answer - it may make sense in specific cases. Obviously, replacing faulty hardware should be preferred whenever possible.
    – peterph
    Jan 13, 2015 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .