devin
By:
devin

Problem with updating Kernel (eth0 now missing)

July 2, 2013 11.7k 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!!!
2 comments
Log In to Comment
6 Answers
dooglio September 6, 2016

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.

Reply
  • zoomua September 9, 2016

    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!

  • phantompang August 4, 2017

    worked perfectly. just not sure why this is necessary.

    Thanks for posting this solution!

devin July 2, 2013

PROBLEM RESOLVED:

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:

http://www.oracle.com/technetwork/articles/servers-storage-admin/signed-kernel-modules-1891111.html
Reply
toepoke March 12, 2015

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.

Reply
xzr April 21, 2015

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

Reply
CEOpx September 4, 2015

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

2.6.18-194.32.1.el5

The –r option will print the kernel release.

uname -s

Linux

-s prints the kernel name.

uname -n

mycomputer.wiivil.com

Print the node name or hostname.

uname -p

i686

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 myserver.wiivil.com 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 (mockbuild@builder10.centos.org) (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

kernel-2.6.18-194.11.3.el5
kernel-2.6.18-194.26.1.el5
kernel-2.6.18-194.32.1.el5

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 boot=/dev/sda

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
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

Reply
hackhowtofaq April 2, 2017
Reply
Have another answer? Share your knowledge.