Question

Resizing my Droplet made it unbootable

Posted February 3, 2018 2.8k views
CoreOSStorage

I resized my Droplet from the old 512MB RAM plan, to the new 5USD/mo 1GB RAM plan, and now it’s not booting. When I view the screen via the QEMU console, it says “Booting from Hard Disk… Boot failed: not a bootable disk”.

I opened a ticket 9 hours ago and I haven’t gotten any response.

I’ve also tried taking a snapshot of the broken Droplet and creating a new droplet from that snapshot, but it just hangs at the “Booting from Hard Disk…” step and never errors out or boots. I’ve even tried this in another region, just in case NYC1 is having problems, but the exact same issue happens.

I can’t download my snapshot, so my data is trapped in Digital Ocean’s data center and I have no idea how to get it out. I also can’t mount the recovery kernel because the CoreOS image doesn’t have this option enabled.

What can I do?

Add a comment
slang
By:
slang
Add a comment

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.

×
2 answers
mzelem February 6, 2018

I had a similar issue when I resized my droplet. It was a ubuntu 14.04 8GB droplet and when the resize was finished I saw the following error:

since I can’t attach in image I’ll type the error by hand:
error: no such device: xxxxx-xxxxxxx-xxxxx-xxxxx-xxxxx.

Press any key to continue…

Gave up waiting for root device. Common problems:

  • Boot args (cat /proc/cmdline)
  • Check rootdelay= (did the system wait long enough?)
  • Check root= (did the system wait for the right device?)
  • Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/xxxxx-xxxxxxx-xxxxx-xxxxx-xxxxx does not exist. Dropping to a shell!

I also got the same problem if I tried to restore from a backup.

However, I discovered that going to the ‘kernel’ tab and changing the kernel from the recovery kernel that it was set to to using an ubuntu 14.04 kernel seemed to fix the problem. Hopefully this helps.

Reply Report
  • cases.webapp April 15, 2018

    Just faced exactly the same problem after users of my system reported that they couldn’t reach website. SSH access to the server just timed out. Went to console access in DigitalOcean and saw exactly the same error as you mentioned.

    Tried fsck from recovery kernel as mentioned here with no luck.

    Followed your advice (switched to ‘Ubuntu 14.04 x64 vmlinuz-4.2.0-36-generic’ kernel) and it logged in perfectly.

    Looks like DigitalOcean introduced new kernels (named 'DigitalOcean GrubLoader v0.1 (20160527) Kernel’ and 'DigitalOcean GrubLoader v0.2 (20160714)’) OR automatically switched my droplet to these and they are not working with my droplet.

    Thanks a lot mzelem for this advice!

    Reply Report
slang February 6, 2018

CoreOS isn’t able to change kernels, so I just waited a full day for the Digital Ocean support people to enable the Recovery ISO. From there I used dd and gzip to transfer the entire disk over ssh and recover files from it on my desktop machine.

The issue ended up being that the resize tool had destroyed the partition table of the disk and I needed to manually look for ext4 superblocks with xxd and grep. Hint: xxd disk.img | grep -E 'ff ?ff ?53 ?ef' will give you a reasonably sized list to look through. From there I managed to mount the disk with an offset I calculated based on the position of the superblock, recover the files, and move them over to a new VPS.

Digital Ocean support provided basically no help and they haven’t even explained why resizing a droplet destroyed my filesystem.

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help