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.
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.
2.6.18-194.32.1.el5
The –r option will print the kernel release.
Linux
-s prints the kernel name.
Print the node name or hostname.
i686
Print the processor type, the i686 signifies a 32 bit processor. If it was a 64 processor it would display x86_64 instead.
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.
CentOS release 5.5 (Final)
This will give you the version of RedHat Linux you are running.
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.
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.
#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.
I also fall into that problem. So, after upgrade from Fedora 19 to Fedora 22 using yum/dnf (https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager?rd=Upgrading_Fedora_using_yum#Fedora_20_-.3E_Fedora_21) machine boot, but does not have eth0 interface. By some reason there no kernel-core, kernel-modules and even glibc installed. After install its from recovery image (https://www.digitalocean.com/community/tutorials/how-to-recover-from-file-system-corruption-using-fsck-and-a-recovery-iso) i could access my machine as usual. Hope it helps to someone.
On some reason I also fall into that problem. So, after upgrade from Fedora 19 to Fedora 22 using yum/dnf (https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager?rd=Upgrading_Fedora_using_yum#Fedora_20_-.3E_Fedora_21) machine boot, but does not have eth0 interface. By some reason there no kernel-core, kernel-modules and even glibc installed. After install its from recovery image (https://www.digitalocean.com/community/tutorials/how-to-recover-from-file-system-corruption-using-fsck-and-a-recovery-iso) i could access my machine as usual. Hope it helps to someone.