[BlueOnyx:23104] Re: fsck problem

[Michael Stauber]

Hi Ernie,

> I have a 5209R server which  is giving the following error on start up:
> 
> [OK  ] Mounted /home.var: fsck 1.1% complete...
> [    4.638527] systemd-fsck[606]: /dev/mapper/VolGroup00-var: Inodes that were part of a corrupted orphan linked list found.
> [    4.638790] systemd-fsck[606]: /dev/mapper/VolGroup00-var: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> 
> What's the correct proceedure for running the required fsck check?
See: https://www.tecmint.com/fsck-repair-file-system-errors-in-linux/

You could run "fsck -A", which will check all filesystems. However, fsck
will only run on filesystems that are currently NOT mounted.

If you only have remote access to the server, then things get a little
complicated. Because ideally you'd boot it into rescue mode and run
"fsck" from there.

If that's not possible and you have to do it remotely, then you should
make sure that you can login by SSH as "root" without having to login as
"admin" first. Because "admin" has his home directory on /home and we
might want to possibly check that as well.

Then stop all services but SSH. Check with "lsof" that nothing has files
on /home open. Once no more files on /var are open, you can unmount /var
this way: "umount /var". Then you can run fsck against it: "fsck -l -M
-t /dev/mapper/VolGroup00-var" Which tells FSCK to lock the filesystem
you're going to check, to ignore mounted filesystems and to run
specifically against /dev/mapper/VolGroup00-var.

However: If fsck already was throwing these kind of errors during
startup I'd get a bit nervous and would consider replacing the disk(s)
in first place. This day and age file system inconsistencies aren't that
common anymore and if they happen, then it's often not an isolated event
that you fix once and then it goes away. Instead it's more likely that
you might be seeing the first stages of an impeding disk related failure
cascade.

-- 
With best regards

Michael Stauber