Droplet is not accessible

This is a community forum and not the best place to reach out to request expedited action on a ticket, updating your ticket or reaching out to us on Facebook or Twitter would be more effective as you would be reaching a member of the DO staff. As this is a public forum our privacy policy doesn’t allow me to provide any specifics related to your tickets here.

That being said, yesterday maintenance in our NYC1 region was ongoing which involved rebooting each hypervisor to apply fixes for the Spectre/Meltdown vulnerabilities. This maintenance means that over the last several days all droplets in this region have been rebooted. Many users have encountered problems due to running older droplets which were still using legacy managed kernels, something which is no longer supported. If this is the case here our team can provide instructions on re-configuring grub (the boot manager) within your droplet to use it’s installed kernel. Another possible issue is if on reboot your droplet experienced problems due to misconfigured services or filesystem check prompts.

The first thing we recommend is to attempt to access your droplet through the console in the control panel which will provide more information on the status of your droplet.

@infofdffb6fa525c5084006acc I feel your pain as that impacted me heavily as well and DO support is kinda silent and unresponsive which sucks… If this is related to a recent change on DO (Intel security issue) and you were running Ubuntu 12.04 kernel, this has saved me: https://www.digitalocean.com/community/questions/missing-kernel-formerly-a-droplet-running-ubuntu-12-04?answer=41541

Please try it following the steps exactly as described and I hope you will get it back working.

My droplet is inaccessible for 28 hours now and yes I have opened several support tickets. My original support ticket was because the droplet was showing signs of data loss, and it is not anywhere near using a high percentage of ram or disk space. At least at that point, I could get to my droplet, it just was getting very slow about changes updating. Then support did something without asking me first, and just emailed me afterward. They attached the recovery iso to my droplet. I guess that is a reasonable thing to do IF you ask your client first and IF you plan to detach the iso afterward, as that is something the client has no access to do.

I did the fsck and listed info about the kernel per the instructions that support sent me in their one and only email to me. Those commands executed fine and showed no problems with file system or kernel. I immediately afterward unmounted the iso and updated my suport ticket to ask them to detach it.

28 hours later. I have not heard from them. I cannot access the droplet by ssh, and from the console I just get the menu displayed by the recovery iso, so it obviously has not been detached. Yes I have rebooted every possible way, through the command line and through the DO website.

My question: It would have been much quicker for me to drive to NY (I don’t live far), find the server my droplet is on and just hit the button to eject the DVD tray of the recovery disk… but I guess everything is virtual, there is no physical tray to eject, right? Is there any command I can use from within the recovery disk (as in it is mounted) to force it to detach?