I was working on my VM when suddenly I realised all my files have been marked as read-only. I found it strange, so I rebooted, and then I was prompted into "BusyBox". For some unknown reason, an error has happened in the file system.

I ran fcsk as shown in the picture below. Im theory, it fixed different errors.

As I am not fully aware of what fcsk has done, and from my previous experience on Windows fixing its file system, I am now a bit sceptical on whether the file system is really "fixed" or there are corrupted files.

  • Can I trust the fixing process?
  • Is there a way I can check that all the data is OK without having to open files one by one?
  • When an error like the one shown in the picture below happens, what can it be the consequences for the actual data in the drive? Could I expect partial file corruption? full file corruption?


Some individual error messages:

File /var/log/journal/d74933508486479e9b07e83b9a036776/system.journal corrupted or uncleanly shut down, renaming and replacing.
pulseaudio[815]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
pulseaudio[815]: Most likely this is a bug in the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA developers.
pulseaudio[815]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
lightdm[931]: gkr-pam: unable to locate daemon control file
dbus-daemon[1035]: writing oom_score_adj error: Permission denied
colord[1570]: failed to get edid data: EDID length is too small
udisksd[1636]: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory
udisksd[1636]: Failed to load the 'mdraid' libblockdev plugin
udisksd[1636]: Error probing device: Error sending ATA command IDENTIFY PACKET DEVICE to '/dev/sr0': ATA command failed: error=0x01 count=0x02 status=0x50 (g-io-error-quark, 0)
pulseaudio[953]: X11 I/O error handler called
pulseaudio[953]: X11 I/O error exit handler called, preparing to tear down X11 modules
systemd[936]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE
systemd[936]: xfce4-notifyd.service: Failed with result 'exit-code'.
kernel: button: module verification failed: signature and/or required key missing - tainting kernel
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
piix4_smbus 0000:00:07.3: SMBus Host Controller not enabled!
sd 2:0:0:0: [sda] 167772160 512-byte logical blocks: (85.9 GB/80.0 GiB)
kernel: sd 2:0:0:0: [sda] Write Protect is off
kernel: sd 2:0:0:0: [sda] Mode Sense: 61 00 00 00
kernel: sd 2:0:0:0: [sda] Cache data unavailable
kernel: sd 2:0:0:0: [sda] Assuming drive cache: write through
systemd[1]: File System Check on Root Device was skipped because of a failed condition check (ConditionPathExists=!/run/initramfs/fsck-root).
systemd[1]: Starting Journal Service...
systemd[1]: Starting Load Kernel Modules...
kernel: fuse: init (API version 7.34)
systemd[1]: Starting Remount Root and Kernel File Systems...
systemd[1]: Repartition Root Disk was skipped because all trigger condition checks failed.
systemd[1]: Starting Coldplug All udev Devices...
systemd[1]: Mounted Huge Pages File System.
systemd[1]: Mounted POSIX Message Queue File System.
systemd[1]: Mounted Kernel Debug File System.
kernel: EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro. Quota mode: none.
  • There should be no problem trusting that fsck has worked correctly. What is more worrying is that "suddenly I realised all my files have been marked as read-only". Without knowing the reason for this we cannot guarantee anything about the integrity of your system. I would look at the error log from your Host. For example, did your host run out of overprovisioned disk space? Apr 24, 2022 at 14:34
  • No, it did not.... I assumed the read-only was a sort of "protection" from the OS after seeing that something was wrong with the file system. Which log files should I check? Apr 25, 2022 at 0:17
  • Your assumption is correct that the read only is protection from the OS on seeing an error. The problem is, if the disk that went read only is the one that collects logs, the error won't make it to a log file. If you have remote logging enabled, you might be able to collect it on another host, or if you can log in, you can check in memory logs with dmesg.
    – user10489
    Apr 27, 2022 at 2:18

1 Answer 1


The output from fsck shows several types of corrected errors:

  • Deleted inode has zero dtime: this is a file that was probably open but deleted when the system crashed. (Sometimes these are labeled as "orphaned" files.) It normally isn't actually deleted until it is closed; so fsck finished the delete operation. (This is a very typical issue after a system crash.)
  • corrupted orphan linked list found: a list of partially deleted files is kept to make the clean up easier later; apparently this list was corrupted, probably due to a partial write of the list. There should be no corruption from fixing this.
  • Free block count wrong: There are blocks that are not part of any file that were not in the free list. Probably a side effect of the above deletions.
  • Inode bitmap differences / Free inode count wrong: There were free inodes that were not marked as free (side effect from the above repairs)

So the changes fsck has made did not corrupt any files.

However, it is worrisome that your filesystem went read only in the first place. This could be caused by the kernel detecting memory corruption or from the disk going fully or partially offline while in use.

If there are hardware errors while writing files, there could be corrupted files. If the disk went offline in the middle of writes, there could be partially written files or files that were created but never made it to disk and are now missing entirely.

So, to answer your points directly:

  • You can trust the fsck fixing process. The messages listed are all fairly benign fixes.
  • You could use something like find / -type f -mtime -1 to look for files modified in the last day and see if any of them appear truncated, or use your knowledge of what the system was doing at the time to see if anything in use is not completely written.
  • Looking for missing files is tricky, but if anything important is missing I'm sure you'll notice.
  • To understand full consequences of this, you will need to determine the root cause that caused the filesystem to become read only. Only then can the full damage be guessed.
  • The R-O was strange indeed. I could not write and the GUI showed crosses on all my home files. Why this happened I have no idea, it was all of a sudden, like 20min idle time after restoring the VM state. The drive was not full: /dev/sda1 79981124 52309532 23565764 69% /. Modified files from last day seem normal, like sys/, proc and the like, but apparently none of my data files. Apr 25, 2022 at 0:26
  • It is typical for linux to remount filesystems read only when it thinks there is something fatal wrong. Better that than to write corrupted data to the fs. You would need to see log messages to know why -- possibly only from dmesg, as they wouldn't have gotten written to the drive.
    – user10489
    Apr 25, 2022 at 0:49
  • I checked journalctl --since "2022-04-22" and it seems to provide some good information... I edited my question with some unrelated messages. Although I cannot see a clear indicator of "ERROR! The system will be mounted as R-O" Apr 25, 2022 at 20:09
  • I don't see that. It says remount ro on error. I don't see an error.
    – user10489
    Apr 25, 2022 at 21:57
  • I could not see the error either... There are many other messages, but those I posted were the majority of the red/yellow ones. I hope fsck worked and there will be no side effects in future Apr 26, 2022 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .