Kernel update

May 31, 2013 14k views
Running a "yum update", CentOS try to install a new kernel. However, I get this: Installing : kernel-2.6.32-358.6.2.el6.x86_64 1/1 grubby fatal error: unable to find a suitable template Verifying : kernel-2.6.32-358.6.2.el6.x86_64 1/1 Installed: kernel.x86_64 0:2.6.32-358.6.2.el6 The installation completes, but the system keep booting on old kernel. Maybe it's related to "grubby fatal error: unable to find a suitable template". I think the kernel is installed but not added to grub. How can I fix this in a safe way?
20 Answers
The kernel is managed through the control panel so you would need to click on the "settings" tab and select a kernel there.

Then power off from the command line and boot the server and the new kernel that you selected will be activated.


Thanks for your reply. This worked. So I can't manage the kernel's using my SSH terminal? For example, if I run "yum remove kernel", will the system still be able to boot?
@andre You have to have the kernel installed on the droplet as well. The droplet won't boot if you specify a kernel that is not found in the droplet.
I did not see the latest kernels in the control panel.
How can I use the latest kenels if they are installed on the droplet but missing in the Control panel ?
Please open up a support ticket so we can add the latest kernel for the image you're using.

For now, you can use the latest one in the control panel.
Got the same "fatal error" today after updating kernel to 2.6.32-431.11.2.el6.x86_64. There's no 2.6.32-431.11.2.el6.x86_64 in control panel - please add it.
But the question still remains: why grubby throws an error "grubby fatal error: unable to find a suitable template" during a kernel update via yum?
sorry I'm a newbie I just wanted to make sure I understood this right
I ran a yum update and got this error

[shuaT@webmaster ~]$ Installing : kernel-2.6.32-431.11.2.el6.i686 3/15
-bash: Installing: command not found
[shuaT@webmaster ~]$ grubby fatal error: unable to find a suitable template
grubby: unexpected argument fatal
[shuaT@webmaster ~]$ Updating : selinux-policy-targeted-3.7.19-231.el6_5.1.noarch 4/15
-bash: Updating: command not found

Am I suppose to go to the go to kernel settings and change to * CentOS 6.5 x32 vmlinuz-2.6.32-431.11.2.el6.i686?

@cytalansky: These aren't commands -- it's just the output of yum update. Make sure you run yum install kernel-2.6.32-431.11.2.el6.i686, and then set the kernel to * CentOS 6.5 x32 vmlinuz-2.6.32-431.11.2.el6.i686 and reboot.
I ran it and got
Setting up Install Process
Package kernel-2.6.32-431.11.2.el6.i686 already installed and latest version
Nothing to do
also in the kernel drop-down there are 2 with the exact same name is this a mistake?
I just selected one however when I ran
cat /boot/grub/menu.lst
I got this
title CentOS (2.6.32-431.el6.i686)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.el6.i686
isn't that the old kernel?
@cytalansky: That's fine, the control panel doesn't update your grub config. You can find out which kernel you're running by running
uname -r

Sorry, I'm confused by this. I too have had problems in the past with "grubby fatal error: unable to find a suitable template", as well as with kernel incompatibilities with snapshots, as a result of which support told me to disable kernel updates in yum.

But here you're saying I do need to update the kernel within the container after all? So I need to remove the "exclude kernel*" from my yum.conf in order to pull down the new update?

Well I've done that, and it downloaded (but again with the grubby error). So what is that about? No-one seems wiling to explain why we get that? Is there any way to prevent it?

  • The kernel that is installed on the droplet must match the kernel that is set in the control panel. So you have a few options on how to do that. The simplest is to just keep them both at the version that existed when you created it.

    The grubby fatal error: unable to find a suitable template stems from that issue. Look in Grub's configuration file, and you'll see that there is a list of kernels in it. The kernel that is set in the control panel must also be found there.

    cat /boot/grub2/grub.cfg | grep vmlinuz

@astar leaving original kernel isn't an option - can't risk exposing security vulnerabilities, so want to keep kernel up-to-date. Sorry, should have said we're running Centos droplets, so grub config is in /boot/grub/grub.conf.
Yep, we'd worked out that the grub file was the problem, but I'm unsure how to fix that, or why we should have to? All seems a bit circular! Doesn't yum change that too when it updates the kernel? Or is it done with a different command, or by manually editing?
The basic question no-one answers is why this happens? On a physical machine, kernel updates via yum just seem to work, it's only in these VM containers there's a problem. Why is that?

  • No, you shouldn't have to worry about the contents of /boot/grub/grub.conf If you keep the installed kernel and the kernel listed in the DO control panel in sync, then it shouldn't be a problem. Just trying to explain that specific error as I thought that's what you were asking about.

    The root issue is that the droplet and hypervisor have to have matching kernels.

I'm rather flummoxed by this as well, i just rebooted the server after selecting
in the dropdown and making sure it's available in /boot as well. Then rebooted and uname reports

so grub.conf is not relevant to what kernel is being booted here?

I faced the same issue and the resolution was to do a full power down and power up instead of reboot(powercycle) from the control panel .

i got the same grub error just now updating through yum:

  Installing : kernel-2.6.32-504.8.1.el6.x86_64                                                                                                                          8/24 
grubby fatal error: unable to find a suitable template

but it is installed:

# rpm -qa|grep kernel
# uname -a

i did a power off and power on but still i can not select the 504 kernel form dropdown

it shows the 431 as latest kernel

how to resolve this???!?!??!!

contaced support...

they know about this error and how to fix it withinn their own image.. but he didn't know why the error is not actually being fixed... he promised to look into that.

anyway, the error is nothing serious though... its more like a warning.

what bothers me though, is the fact that untill this error happened i was not even aware that digitalocean 'controls' your kernels.

for anyone who is not aware how it works (likely every new customer) here a short explanation:

first of all, an article about the grub error and solution can be found here:

it suggests to remove grub.conf and the symbolic link.

after that you install a new kernel.

HOWEREVER.. this new kernel will NOT be loaded on reboot.

for this you need to go into your droplet control panel en select 'settings' -> 'kernel'-tab
there you select the kernel you just installed.

next, you completely power off your droplet and turn it on again.

your new kernel should be loaded.

sometimes a new kernel gets released and you install it BUT it is not listed in the dropdown.

all you can do at this point is wait for digitalocean's admins to add it...
well... naging them to hurry up is also an option ;)

it's all a bit cumbersome but they probably have their reasons.

all i wish is that they finally fix the grub warnings in their image and somehow make it more clear how this kernel things works to newbies.

Basically you'll have to set the kernel in the dropdown list on your control panel.

It's a long and painful story, but this is to do with Digital Ocean using "KVM" virtualisation (ie. and not "Xen" or what-have-you) which lives inside the kernel itself.

Practially, for CentOS or Fedora you can update like this to exclude the kernel:

yum --exclude=kernel* update

(I haven't for the life of me been able to find the apt-get equivalent of this...)

Hope this helps.

I use "KVM" virtualisation in many Data Centers and have never had problems with kernel updates.

I'n not happy that DO controls which kernel I can run and I would like to know how to bypass this.

I'm going to try " " now and if it doesn't work and I can't install an own kernel then I'm afraid DO is not for me.

The method on is really dumb, don't use it, it doesn't do anything good.

Have another answer? Share your knowledge.