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!!!
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
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.
Want to learn more? Join the DigitalOcean Community!
Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.
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:
it told me “failed to bring up eth0.” I grepped around in the
dmesgoutput, and found this line of interest:Edited
/etc/network/interfacesand changedeth0toens3and viola!,ifup ens3worked.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