I have built a droplet with Ubuntu-14.04 and immediately upgrade it to a pre-release version of Ubuntu-16.04. Everything seemed working fine, and I installed and set up several servers (apache2, postfix, dovecot, …) but the kernel remained at 3.17.0-71.
Since the official 16.04 was released, I did “apt-get dist-upgrade,” which has installed the kept-back kernels along with many other packages. However, it has made no changes in terms of the kernel version to be booted.
Shortly, I found that on a digitalocean droplet, the kernel should be selected in the control panel. I did select Ubuntu-16.04 kernel-4.4.0-21 in the menu and started the droplet but it wouldn’t respond. “Console Access” revealed that the droplet started up but had no ethN I/F.
With putting back the kernel to Ubuntu-14.04 kernel-3.17.0-71, everything has started working properly.
Are there any ways to work around this problem around the missing ethN I/F? Or must I port everything to a newly created droplet?
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Hi, after you changed the kernel to 4.4, you need to change your network interface name in /etc/network/interface as the kernel change eth0 to something like ens3 (like my case - confirm it with ip addr show) Then restart networking service you should be fine :)
Hi, after you changed the kernel to 4.4, you need to change your network interface name in /etc/network/interface as the kernel change eth0 to something like ens3 (like my case - confirm it with ip addr show) Then restart networking service you should be fine :)
Hi, after you changed the kernel to 4.4, you need to change your network interface name in /etc/network/interface as the kernel change eth0 to something like ens3 (like my case - confirm it with ip addr show) Then restart networking service you should be fine :)
Hi, after you changed the kernel to 4.4, you need to change your network interface name in /etc/network/interface as the kernel change eth0 to something like ens3 (like my case - confirm it with ip addr show) Then restart networking service you should be fine :)
Droplets originally based on 14.04 still use our older kernel model where the kernel is managed outside of the Droplets themselves. This article explains how this works and shows how to update your kernel:
The key is to make sure the version in the panel and the Droplet match. You can check the kernels available to your Droplet by running:
ls /boot/vmlinuz*
So if you selected “Ubuntu-16.04 kernel-4.4.0-21” in the control panel, you’ll need to have this in the output:
/boot/vmlinuz-4.4.0-21-generic
If you’re still running into issues, please go ahead and open a support ticket so the team can take a closer look.
Note: For Droplets based on 16.04, the kernels no longer need to be managed through the control panel. So depending on your use case, it might just be better to move to a new Droplet rather than update in place.
Your best option at this point would be to port your applications to a new server running Ubuntu 16.04. This will ultimately save you time, and be the most surefire way to get up and running on the latest kernel.
This comment has been deleted
I had the same problem upgrading the 3.13.0-57 after upgrading to Ubuntu 16.04. After a lot of research I decided to create a ticket at DO and in a couple of hours I got a detailed response, I think you can find the ticket in the support section.
They chose for me the
DigitalOcean GrubLoader v0.2 (20160714) Ubuntuand after a short reboot I had the 4.8.0-53-generic kernel, in about 30 seconds.Everything seems to be working fine now, had no issues with the ethN interfaces.
I had the same problem upgrading the 3.13.0-57 after upgrading to Ubuntu 16.04. After a lot of research I decided to create a ticket at DO and in a couple of hours I got a detailed response, I think you can find the ticket in the support section.
They chose for me the
DigitalOcean GrubLoader v0.2 (20160714) Ubuntuand after a short reboot I had the 4.8.0-53-generic kernel, in about 30 seconds.Everything seems to be working fine now, had no issues with the ethN interfaces.
I should have added this comment much earlier…
I didn’t have the guts to manipulate the Ethernet I/F after upgrading my kernel to 4.4.0, or to re-install Postfix/Dovecot/Mailman to a newly installed 16.04, and did nothing until recently. One day, just after a routine backing up, I ventured to try “DigitalOcean GrubLoader v0.2 (20160714) Ubuntu” at the control panel. It worked fine! Although it’s not exactly the same with the brand-new installation (that is, it’s not “internally managed”), it uses the latest kernel which is installed with “apt upgrade.”
I did this one month ago, and the new drop let has experienced kernel updates twice without any troubles. I am very pleased with the mechanism, and my only complaint is that it’s well hidden :-)
I should have added this comment much earlier…
I didn’t have the guts to manipulate the Ethernet I/F after upgrading my kernel to 4.4.0, or to re-install Postfix/Dovecot/Mailman to a newly installed 16.04, and did nothing until recently. One day, just after a routine backing up, I ventured to try “DigitalOcean GrubLoader v0.2 (20160714) Ubuntu” at the control panel. It worked fine! Although it’s not exactly the same with the brand-new installation (that is, it’s not “internally managed”), it uses the latest kernel which is installed with “apt upgrade.”
I did this one month ago, and the new drop let has experienced kernel updates twice without any troubles. I am very pleased with the mechanism, and my only complaint is that it’s well hidden :-)
I should have added this comment much earlier…
I didn’t have the guts to manipulate the Ethernet I/F after upgrading my kernel to 4.4.0, or to re-install Postfix/Dovecot/Mailman to a newly installed 16.04, and did nothing until recently. One day, just after a routine backing up, I ventured to try “DigitalOcean GrubLoader v0.2 (20160714) Ubuntu” at the control panel. It worked fine! Although it’s not exactly the same with the brand-new installation (that is, it’s not “internally managed”), it uses the latest kernel which is installed with “apt upgrade.”
I did this one month ago, and the new drop let has experienced kernel updates twice without any troubles. I am very pleased with the mechanism, and my only complaint is that it’s well hidden :-)