How to Fix Read‑Only Linux VMs After an Unexpected Crash with fsck

Problem description: After a compute node in a private OpenStack+KVM cloud failed and was restored, all Linux VMs on that node became read‑only, showing “Read‑only file system”.

Root cause: The VMs were not shut down cleanly, causing filesystem errors on the virtual disks.

Solution: Run fsck manually. Reboot into single‑user mode as root and execute: fsck.ext3 -y /dev/vda3 Note: Use fsck.ext3 for ext3 filesystems and fsck.ext4 for ext4. /dev/vda3 is the root partition. After fsck finishes, reboot the system. The process may take time; do not reboot prematurely.

Additional knowledge – fsck overview: fsck can scan and repair filesystems, but must be run in single‑user mode, repair mode, or on an unmounted device. Running it on a mounted, active system can cause damage.

Common fsck tools include fsck, fsck.ext2, fsck.ext3, fsck.ext4, fsck.msdos, fsck.cramfs, fsck.ext4dev, fsck.vfat. Use the tool matching the filesystem type.

Parameters for fsck.ext3 (example for /dev/vda3):

-a non‑interactive mode, auto‑repair

-c check for bad blocks

-C verbose output for monitoring

-d detailed execution

-f force check

-F clean block cache before checking

-l add listed bad blocks to the bad‑block list

-L clear all bad‑block flags

-n read‑only mode (no changes)

-P set inode size handling

-r interactive mode

-R ignore directories

-s sequential check

-S similar to -s

-t display timing information

-v verbose output

-y assume “yes” to all prompts

Optional parameters include -b (specify superblock start), -B (block size), -I (inode buffer size), -V (version).