We're reviewing the rollout of allowing users to boot their own kernels, once we have a better time estimate on the work required and whether or not there are any complications with existing droplets we can provide a clear time estimate on a rollout schedule for this.

IMHO this is a pretty important feature. The problem doesn't just apply to ubuntu, arch has it as well (most likely this is just how the system is designed).

It's a shame because when you run a system upgrade, if you swap kernels with arch you kill your machine :)

Overtime we will be building out more features that give users more control but for now we are restricting certain pieces to make administration of the backend simpler.

Of course like everything else it all depends on upvotes from our customers, if people start chiming in and raising this to the top of the most wanted list we'll certainly reprioritize our roadmap to accomodate them sooner.

Thanks

Still no ETA to fix this gaping security hole?

Yes! This is *NOT* a feature request - this is a MASSIVE security problem - you're not allowing your customers to apply security updates. Shocking.

I'd certainly find this usefu - it's almost a show-stopper for me.. At the moment, an update appears to happen smoothly, then syslog fills up with getty hvc0 respawning messages every 10 seconds. Not being able to apply security updates (and software updates - as of today, in ubuntu 12.04, there are 185 of them!) is a big mistake in the implementation. As others have said, this needs to have rather more priority than is currently apparent. Otherwise, I'm one satisfied customer, but this will make me reconsider if left unresolved.

As others have pointed out, this is a security issue. Please fix.

Thanks to everyone for up-voting we have started work on the backend to allow customers to run their own kernels.

That's excellent news. Thanks.

Thank you! I only just started using digitalocean as my VPS, but so far I am very impressed in the level of responsiveness you have to user requests.

Used my last vote on this as this is critical for me! Now I need a way of obtaining more votes!

In the works on this one =]

Now that the SSD is out of the way we'll be able to make more headway on features again! :)

As a workaround in the meantime - kexec can be used. I've a Droplet that was installed as Ubuntu 11.10 (so still boots with 11.10's kernel and initrd) but has been upgraded with apt to 12.04. It now boots, and kexec's the up-to-date kernel and initrd from within the droplet. Ugly but it works...

If others are interested in more details then let me know...

Hi Chris,

That sounds very interesting, if you would like to write up an article on it we can post it to our community for others to read and comment on.

Not sure if this is 100% correct, but this works for me in Ubuntu 12.04:

1) First install kexec-tools:
sudo aptitude install kexec-tools

2) Update your system through apt:
sudo aptitude update
sudo aptitude safe-upgrade

2) Load new kernel into memory (eg. 3.2.0-36-virtual, find the most recent with "ls /boot" or "dpkg --list | grep linux-image"):
sudo kexec -l /boot/vmlinuz-3.2.0-36-virtual --append="`cat /proc/cmdline`" --initrd=/boot/initrd.img-3.2.0-36-virtual

3) Reboot into loaded kernel:
sudo kexec -e

4) Check if everything worked as expected:
uname -a

If you reboot the system by other means than kexec -e, the digitalocean kernel will be loaded. So you'll need a startup script which will automate the above process. I do not know how to do this cleanly.

More information on kexec can be found in the manpages:
http://manpages.ubuntu.com/manpages/precise/man8/kexec.8.html

To fully automate the kernel loading and rebooting, use the following script (should be run as root):

#!/bin/bash
LOAD_KERNEL=`dpkg --list | grep linux-image-3 | sort -nr | sed -n 1p | cut -d' ' -f3 | sed 's/linux-image-//'`
kexec -l /boot/vmlinuz-$LOAD_KERNEL --append="`cat /proc/cmdline`" --initrd=/boot/initrd.img-$LOAD_KERNEL
kexec -e

I'm sorry for spamming, but I've found another solution. Again using Ubuntu 12.04. Apparently, kexec already has auto-loading scripts. So let's activate those:

1) The default Digital Ocean Ubuntu 12.04 image has 'grub' installed, replace by 'grub-pc'
sudo aptitude install grub-pc

There is a question about chain-loading, accept the proposed solution.

2) Activate the kexec initscript
sudo nano /etc/default/kexec

Set the following lines to true:
LOAD_KEXEC=true
USE_GRUB_CONFIG=true

3) Done! Everytime the system is rebooted, kexec will take over the reboot process and load the 'default' kernel, which always is the latest one if you use aptitude or apt-get to update your system.

The only downfall is that these script will only be called on reboot. So if you boot a system which has been powered down, you will still boot into the 'old' kernel.

Hi Dennis,

Thanks for posting this I think it would also be useful if you opened up a forum topic about it as well:

https://www.digitalocean.com/community/questions

We've been a bit delayed on this issue due to growth but we have had a large number of customers request this so we hope to have a beta solution for this deployed for public use in the next 2-3 weeks.

Thanks

I may not need to update the kernel image, personally, but I do need to be able to set a kernel option temporarily in order to transition my Arch Linux VM from sysvinit to systemd. You have to set the init= parameter to systemd, boot, remove sysvinit and add systemd-sysvcompat... If you don't use systemd for init, then you can't shut the VPS down cleanly after removing sysvinit.

Another option would be just reinstalling an Arch image that uses systemd by default. I haven't yet gone very far in setting up my little Arch VPS (I've just been having fun exploring the Digital Ocean up to this point ;) ).

Got to agree - this would be an excellent feature to have