Installing stock CentOS kernel on an OVH or Kimsufi server

I recently signed up for a small dedicated server at Kimsufi.co.uk for the grand price of £14 a month which I think is pretty good price for what you get.

Brand	Intel
Model	Celeron / Atom
Frequency	1.20+ GHz
Architecture	64 bits
NIC	FastEthernet
Memory	2 GB
Hard disk	1 TB
FTP Backup	100 GB
Bandwidth	Heaps more than I need :-)

The machine itself is nothing special but they do have remote management and you can install a variety of Linux and Windows operating systems. I am quite happy with their service and management tools but I wasn't happy with the fact that they run their own custom kernels on them. The kernel that they install is a 'grsec' hardened 3.2 kernel but this caused a variety of issues when doing 'yum update', mainly dependency issues. I Googled around and found a few different solutions on remotely installing CentOS which were all basically variations on the way I describe in a previous post using [grub to re-install](http://www.thegoldfish.org/2009/12/reinstall-centos-using-grub/). Whatever I tried with this including [using VNC](http://forum.ovh.co.uk/showthread.php?t=4991) and attempting a fully automated install with a tested kickstart file it would become unresponsive when rebooting into the OS the first time.

Instead of all these methods I should have been thinking inside the box instead of outside it :-(

Solution:

yum install kernel

Then add the following stanza to /etc/grub.conf modified to suit the kernel that was installed (Check under /boot/ for the file names).

title CentOS (2.6.32-220.23.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-220.23.1.el6.x86_64 root=/dev/sda2 ro
        initrd /initramfs-2.6.32-220.23.1.el6.x86_64.img

and change:

default=0

to:

default=1

After a reboot we end up with the correct stock kernel and the yum issues disappear.

The system is much closer to a normal installation and the only thing I am still unhappy with is the filesystem mounted at / is a physical partition instead of on LVM. This should be easily resolvable by creating a new logical volume and copying everything over and some updates to /etc/fstab and /boot/grub/grub.conf to point at the logical volume and a selinux relabel but I will leave that for another day.