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.

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.

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.

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.

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.

<br>PROBLEM RESOLVED: <br> <br>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. <br> <br>What you have to do in order to work around the issue is to do something similar to this: <br> <br>{ 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 } <br> <br>Step 1: Change to the location of the virtio_net.ko module <br># cd /lib/modules/2.6.32-358.11.1.el6.x86_64/kernel/drivers/net/ <br> <br>Step 2: Strip the public key information from the file using the “objcopy” utility. <br># objcopy -R .note.module.sig virtio_net.ko vnet.ko <br> <br>Step 3: Load your stripped version of the driver into the kernel and (voila) <br># insmod vnet.ko <br> <br>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: <br> <br>http://www.oracle.com/technetwork/articles/servers-storage-admin/signed-kernel-modules-1891111.html <br>

For reference PredictableNetworkInterfaceNames

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.x86_64.img line in the first kernel stanza means that the initramfs image is actually located at /boot/initramfs-2.6.32-22.el6.x86_64.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

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

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.