Problem with updating Kernel (eth0 now missing)

Posted July 2, 2013 23.1k views
I have a Droplet that I have been trying to get access back to via eth0 however have failed at everything i have attempted to do. What happened was I updated my Droplet today to apply all patches to my CentOS 6.4 instance. It installed the latest kernel that came from the REPO and it removed the other kernels on the system. I did not realize that the Droplet doesn't really use the kernels that is configured inside your Linux instance. The problem I am having is the kernels that are available to me from within the "Console" settings none of them work allowing me to have an eth0 device. I am assuming because on the boot it is looking for the kernel modules to exist inside my instance but they do not. Now that I no longer have Internet access I am unable to reinstall the kernel versions that I need to have there in order for the system to boot, so I am inbetween a rock and a hard place. I don't want to loose any data on my instance and I don't see any easy way to either get my data moved off this instance onto another or to regain my "eth0" device so I can get it back onto the Internet. If anyone can Help this would be great!!!

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.

Submit an Answer
6 answers

This happened to me just today. I stopped my droplet, made a snapshot, then tried to bring it back up again. I could not SSH in. The console showed me that eth0 was not up. When I typed in the command:

ifup eth0

it told me “failed to bring up eth0.” I grepped around in the dmesg output, and found this line of interest:

[    0.889859] virtio_net virtio0 ens3: renamed from eth0

Edited /etc/network/interfaces and changed eth0 to ens3 and viola!, ifup ens3 worked.

So it looks like the more modern kernels are changing the main interface names.

  • Had exactly the same issue after scheduled droplet migration yesterday (running Ubuntu 16.04 with vmlinuz-4.4.0-28-generic kernel).
    Renaming eth0 to ens3 in /etc/network/interfaces solved the problem. Thanks!

  • worked perfectly. just not sure why this is necessary.

    Thanks for posting this solution!


It appears that if the Kernel version selected via the Web Interface under Settings -> Kernel is set to a specific version and that version of the Kernel is not installed on the CentOS/Linux instance the modules won't load because they kernel uses private/public keys to validate the modules are legit. So in my case the kernel was not loading the drivers for the ethernet because it failed the public key check.

What you have to do in order to work around the issue is to do something similar to this:

{ Assuming that you have kernel version 2.6.32-358.11.1.el6.x86_64 installed locally but the system is trying to boot 2.6.32-358.6.1.el6.x86_64, you could use the drivers from the new version but need to delete the public keys so it will load into the module just fine }

Step 1: Change to the location of the virtio_net.ko module
# cd /lib/modules/2.6.32-358.11.1.el6.x86_64/kernel/drivers/net/

Step 2: Strip the public key information from the file using the "objcopy" utility.
# objcopy -R .note.module.sig virtio_net.ko vnet.ko

Step 3: Load your stripped version of the driver into the kernel and (voila)
# insmod vnet.ko

This is the article that I came across on the net that really helped me figure out how to strip the public key information from the modules:

I had a similar issue. I tried the instructions above but it didn’t work for me. There were too many incompatibilities between the kernel was using and the kernels installed on my droplet.

In the end, DO Support fixed this for me. They manually installed the kernel.

It took DO Support a long time (i.e., more than 3 hours) to reply to my ticket, however they were able to fix it quickly once they started working on it. It should be helpful for others to know that DO Support is able to fix this manually.

nice one dude, had a similar problem after a physical node failure and this one fixed it

I had to follow this to get my Kernels matching and eth0 back up, running Centos 6.7 Final

Use the command uname to print system information in Linux.

uname -r


The –r option will print the kernel release.

uname -s


-s prints the kernel name.

uname -n

Print the node name or hostname.

uname -p


Print the processor type, the i686 signifies a 32 bit processor. If it was a 64 processor it would display x86_64 instead.

uname -a

Linux 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686 i686 i386 GNU/Linux

Print all the information except omit –o and –I if unknown.

cat /etc/redhat-release

CentOS release 5.5 (Final)

This will give you the version of RedHat Linux you are running.

cat /proc/version

Linux version 2.6.18-194.32.1.el5 ( (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Wed Jan 5 17:53:09 EST 2011

This will give you who and when compiled the kernel and what gcc compiler was used to build it.

rpm -q kernel


This will list all the kernels installed on your system.

If the new kernel causes issues then you have the option to revert to the older version. You may have to boot the system with the boot media and re-configure the boot loader. The AMD and Intel architecture uses GRUB boot loader. You will need to make changes to /boot/grub/grub.conf to activate a different default kernel.

Please not that when the kernel is installed using rpm, the kernel package creates an entry in the boot loader configuration file for the new kernel. But the rpm does not configure the new kernel to boot as the default kernel, this must be done manually.

Below is an example of /boot/grub/grub.conf. The directive default=0 means that default boot kernel is 0, which is the first stanza that starts with the title entry.

So in this case title CentOS (2.6.18-194.32.1.el5) is stanza 0. When the system boots this kernel will be used. The title contains the kernel version number 2.6.18-194.32.1.el5, which must match with the version number in the kernel /vmlinuz-2.6.18-194.32.1.el5 (this is the line below root.

If a separate /boot/ partition was created, the paths to the kernel and the initramfs image are relative to /boot/. This is the case in Example 23.2, “/boot/grub/grub.conf”, above. Therefore the initrd /initramfs-2.6.32-22.el6.x8664.img line in the first kernel stanza means that the initramfs image is actually located at /boot/initramfs-2.6.32-22.el6.x8664.img when the root file system is mounted, and likewise for the kernel path (for example: kernel /vmlinuz-2.6.32-22.el6.x86_64) in each stanza of grub.conf

To clarify further, stanza 0 starts with title CentOS (2.6.18-194.32.1.el5)
Stanza 1 starts with title CentOS (2.6.18-194.26.1.el5)
Stanza 2 is title CentOS (2.6.18-194.11.3.el5)

To change the default boot kernel to stanza 2 simply change the line default=0 to default=2.

grub.conf generated by anaconda

Note that you do not have to rerun grub after making changes to this file

NOTICE: You have a /boot partition. This means that

all kernel and initrd paths are relative to /boot/, eg.

root (hd0,0)

kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00

initrd /initrd-version.img


title CentOS (2.6.18-194.32.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.32.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-194.32.1.el5.img
title CentOS (2.6.18-194.26.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.26.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-194.26.1.el5.img
title CentOS (2.6.18-194.11.3.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.11.3.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-194.11.3.el5.img