Hi,
In my last update, I noted that certain Droplets in fact already used their own bootloaders and "internally managed" kernels. I'm glad to say that these changes have been backported to other distros as well. All new Droplets now use their own bootloader.
We've also provided an upgrade path for older Droplets. In order to use the "internally managed" kernels without rebuilding your Droplet, you can now set the "DigitalOcean GrubLoader" from your Droplet's kernel menu.
You can read more about how this works in this tutorial:
https://www.digitalocean.com/community/tutorials/how-to-update-a-digitalocean-server-s-kernel
If you have any questions about the changes, please open a support ticket so the team can clarify any concerns you have.
https://cloud.digitalocean.com/support/tickets/new
Thanks!
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.
Attachments Open full size
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 :)
Attachments Open full size
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
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
As others have pointed out, this is a security issue. Please fix.
Attachments Open full size
Thanks to everyone for up-voting we have started work on the backend to allow customers to run their own kernels.
Attachments Open full size
That's excellent news. Thanks.
Attachments Open full size
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.
Attachments Open full size
Used my last vote on this as this is critical for me! Now I need a way of obtaining more votes!
Attachments Open full size
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! :)
Attachments Open full size
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...
Attachments Open full size
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.
Attachments Open full size
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
Attachments Open full size
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
Attachments Open full size
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.
Attachments Open full size
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
Attachments Open full size
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
Attachments Open full size
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 ;) ).
Attachments Open full size
Got to agree - this would be an excellent feature to have
Attachments Open full size