System crash and unclean reset, fsck necessary?

Hello everyone,

I’m basically wondering if there is any manual action that has to be taken on the ext4 root file system to ensure file system integrity. I was running a Windows game via Steam Proton and everything just froze up with no keys responding, no virtual consoles, no REISUB (already enabled via guide) and the only option was pushing the case reset key (first time in 4 years actually on this computer). This is a new installation and I want to make sure it lasts with no surprise problems. When the system booted up it went straight to the login screen and I didn’t see anything about fsck in the console output. Is the system smart enough to repair itself and is the journaling file system alright (I have used Windows for the past 5 years and I’m uncertain)?

In your /etc/fstab file, you should be able to see which mounts will have fsck performed on them automatically, when mounted. See here:

Alright, the Arch Wiki could use an update as the /etc/fstab refers to the fsck column as pass on my computer which is in fact set to 1 for root. This means that that the file system check should be enabled, am I correct?

Is there any way I can know that it ran and the system is free of errors?



Have a look at:

journalctl -x -b 0 | grep fsck

systemctl status systemd-fsck-root.service

man systemd-fsck-root.service

You could also check the health of your RAM sticks and disk.

1 Like

Thanks, according to the logs, the file system is “clean” and the service is enabled. The lost+found directory is also empty, therefore, I am assuming that everything is fine and no further investigation is necessary.

If fsck has nothing to declare, then your filesystem is fine.

However if you get another freeze at some point into the future, I would suggest to check the health of your disk and RAM (smartctl, memtest).

Thanks for your assistance, if a crash happens again I will investigate, however, it is unlikely that this Ryzen 5950x system has issues as I performed extensive stability testing/burn in when I built it and everything checked out (the SMART data is also fine).

Believe it or not, the first 5950x CPU had a bad core, requiring positive voltage offset so I replaced it, and the first kit of RAM also had to be RMA’d due to defects.