My droplet is down for 16+ hours - there is no response to the ticket (#2848589) since it’s creation. Please look into this issue urgently!

The console says “No filesystem could mount root, tried: Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block”

Submit an answer

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!

Sign In or Sign Up to Answer

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.


Thank you for your extremely helpful reply. Your insight helped me understand and resolve the issue. And, yes, I did hear from DO Support after 28 hours of my ticket.

Their response was "Looking over the droplets console this appears to be a filesystem related issue. The best option will be to investigate this via recovery mode.

You can enable and disable the recovery environment directly from the Cloud Panel. This is in the “Recovery” options available from your Droplet page.

To use this, start with turning off the Droplet ( either through web console or from Cloud Panel / API ) and then use the Recovery option “Boot from recovery ISO”. On the next time you turn the Droplet on, you will be able to access the recovery environment from the web console.

You can read more about the using the recovery environment on this post:

Once in the Recovery environment you can use the options to perform some maintenance, investigate the issues in configurations or prepare data for migration and redeployment.

For running file system checks, you can use option #2 from the recovery environment menu. If this comes back without any errors, you can use the other options to mount the disk and access a shell to explore the filesystem."

My DO droplet did not offer an option to chose another kernel for the server to boot from as suggested by you.

I took the following steps after logging into the recovery mode from the DO interface.

  1. Option 5 - Attempt to ‘chroot’ into installed system
  2. check /boot/grub/grub.conf for the latest kernel and/or the history of previous kernels by versions. Wrote down each version on a paper.
  3. Deleted the kernels, one at a time, using 'sudo yum remove kernel-x.xx.x.x"
  4. Checked for updates using ‘sudo yum update all’
  5. Installed a fresh version of the latest kernel using ‘sudo yum install kernel’
  6. Restarted the droplet. AND Voila!

Additional information that maybe useful for fellow community members facing similar issues:

  • I did try to fix the grub.conf file for errors with the latest kernel update which did not have the initrd entry. But that did not help.
  • There are several alternative solutions across multiple discussion groups, that are much safer than deleting all the kernels and then installing a fresh one.

I hope the support team will get back to you shortly (if they haven’t responded till now).

Just to mention I had the same error and I was able to fix by simply choosing another kernel from which the server to boot from. The server was having issue with the kernel I was previously trying to use.

Hopefully your server will be online shortly.