2

I have had this happen a couple times - I have a ClearOS Enterprise 5.2 box, and due to a power outage or similar, it ends up showing an error at boot and saying that fsck needs to be run (I think it said with (or without?) the -a parameter).

The problem is, I need this box to be headless, at a remote location (miles away)!

SO, I need to come up with a solution on how to either have it automatically repair itself, without someone to be present with a monitor and keyboard.

Another possibility is to simply avoid the issue all together - maybe there is something that can be changed so it's very unlikely to happen (I am unable to avoid the power outage of course - at least not practically).

Finally, maybe it can be boot off a read only media (cd) or file system or similar? At least the base OS, so that it would always at least boot with enough configuration that might allow remote access, or basic connectivity?

Scott Szretter
  • 1,860
  • 11
  • 42
  • 66

1 Answers1

1

Note: This works on CentOS and RHEL. I believe it to work on ClearOS as well since it is based on RHEL. You can check if it looks at these things by looking in /etc/rc.d/rc.sysinit - which is the script that decides the fsck stuff I have described below.

You can disable that in /etc/fstab, the sixth field on each line defines whether or not fstab should run. 

/dev/sysvg/rootlv     /        ext4      defaults 0 0 <-- that

The above will disable it. If instead you want to make sure it runs with -y option so it will autocorrect errors create the file /etc/sysconfig/autofsck and add these lines to it: 

AUTOFSCK_DEF_CHECK=yes
PROMPT=yes
AUTOFSCK_TIMEOUT=10

If you do this, the server will run fsck automatically and correct things by itself if it has been rebooted the hard way.

Frands Hansen
  • 4,617
  • 1
  • 16
  • 29
  • I'm sorry - I just have to ask.. I thought foreground fsck was a issue on filesystems not journaled? Does't ext4/xfs/etc use background fsck? – pauska Jan 28 '12 at 14:17
  • If the filesystem is marked not clean it will require fsck. You can prevent long fsck's on ext3 by using LVM snapshots and background check those. On ext4 they did change some things to speed it up (see more http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_ext4) – Frands Hansen Jan 28 '12 at 14:40
  • If I were to disable it, I understand the risk is running with a corrupt file system, correct? But what's the risk of automatically correcting things (which I think is what I want)? – Scott Szretter Jan 28 '12 at 14:57