Hey there,

Just wanted to step in and offer a quick update here. It’s no longer necessary for us to import new kernels. Instead, if you’re using one of our older images, you can ensure you’re using the newest kernel by switching to our “GrubLoader” kernel in the control panel, and performing a full power off/on.

This will allow your Droplet to boot using your locally installed kernels rather than the ones on our HV that we manually used to import.

Newer images boot like this automatically, but older images need to be switched over manually.

More info here: https://www.digitalocean.com/community/tutorials/how-to-update-a-digitalocean-server-s-kernel

Thanks,
Eris
Customer Success Engineer

@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?

I’m rather flummoxed by this as well, i just rebooted the server after selecting
vmlinuz-2.6.32-504.3.3.el6.x8664
in the dropdown and making sure it’s available in /boot as well. Then rebooted and uname reports
2.6.32-431.17.1.el6.x8664

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
kernel-2.6.32-431.29.2.el6.x86_64
kernel-2.6.32-504.8.1.el6.x86_64

# uname -a
2.6.32-431.1.2.0.1.el6.x86_64

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:
http://www.itekhost.net/grubby-fatal-error/

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 digitalocean.com 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 “ http://www.itekhost.net/grubby-fatal-error/ ” 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 http://www.itekhost.net/grubby-fatal-error is really dumb, don’t use it, it doesn’t do anything good.

I solved the problem by editing /boot/grub/grub.conf and updating the kernel argument “root=UUID=xxxxxxxxxxx” to use a UUID that actually exists. I found out the UUID of my ’/’ partition using ‘blkid’. After editing grub.conf, I did a 'yum reinstall kernel’ and there were no grubby errors anymore.

If you don’t have any luck using a UUID, you could also try using root=LABEL=DOROOT where 'DOROOT’ is whatever is returned from something like 'sudo e2label /dev/vda1’

Hope this helps someone :)