How to Fix: "Failed to open serialization file readonly file system"

Hi, I performed apt update +upgrade and rebooted the machine when prompted to do so. Now my droplet fails to boot and gives a message of “Failed to open serialization file readonly file system” Is there any guidance on how to resolve this issue?

  1. As per the issue could be a mismatch between the uuid in /etc/fstab and output of uuid. This is not the issue here.

  2. I am able to boot by: enabling rescue mode ->entering interactive shell -> typing reboot -> selecting boot from harddisk.

  3. But Normal boot fails.

  4. I have raised a ticket with DO waiting for a response

Submit an 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.

Accepted Answer

Ok so after running up a new droplet with my week old backup and updating to the point that it broke as described. I identified that it was the snapd package (snapd/bionic-updates 2.42.1+18.04 amd64 [upgradable from: 2.40+18.04]) that caused the break.

I then booted via the recovery console and removed the snapd package. I then shutdown and switched back to booting via the standard method and the test system is now working as expected.

I am now going to fully update the test system and reboot.

If this works I will replicate this to my live system.

Edit: This has worked and I have replicated to live system and all is working. The ‘snapd’ package was the issue for me, once removed all was good.

Uninstalling snap solved my problem as well. I’m going to upgrade to a newer version of Ubuntu to see if this problem persists there.

Great thread! I just found my way here after discovering snapd caused my 18.04 ubuntu server to go into read-only mode after a reboot.

I was using snapd to install certbot, but I found a tutorial with installation without snapd. See:

@ghostseven Thank you, we had the same problem and running:

apt rempve snapd

made our droplet boot as normal again.

Any updates on this or at least a link to the Canonical bug?

@ghostseven Thanks a lot! Can you also file a report at

DO have not been overly helpful to be fair. I am however working on the problem and have made some progress. I had a backup from a week ago that I have restored to a new droplet. I have been working through the updates and have identified (for me at least) which update has caused this issue.

I updated the snapd package (snapd/bionic-updates 2.42.1+18.04 amd64 [upgradable from: 2.40+18.04]) and it replicated the fault. I am just in the process of booting the test droplet to remove this package and see what occurs. Hold this space and I will report back :)

@ghostseven @alexanderlndbrg Did you get any resolution from DigitalOcean’s support staff?

In my case, Once in a day someone responds, "Hey we checked your console. Everything is fine!"

My response of “That’s because it is booted in recovery mode. It does not work in normal mode” falls on deaf ears…

I have also posted to serverfault without any response

Just wanted to chime in to say that I had the exact same issue right now. The recovery-reboot method worked for me as well. I’ve also created a ticket.

I am having the exact same issue after performing an update and upgrade. Attempting to boot the droplet using a recovery shell.

Edit: If i boot into recovery then, reboot and select boot from harddisk the droplet boots. Exact replication of above behaviour.

OS is Ubuntu 18.04.3