when the Red Hat 5.x workstation of a user crashes and leaves its filesystems with errors, on the next boot, it ask for the root password to enter single mode and run fsck manually.

This is annoying because the user can't use his workstation and we need to send someone just to run fsck.

Users don't store any valuable data on their workstations, so is there a way to configure this fsck to automatically run on errors without any password ?

up vote 1 down vote accepted

What's probably closest to the "official" way to do this not normally recommended (for good reason!) thing:

echo ' -y ' > /fsckoptions
chattr +i /fsckoptions

All versions of /etc/rc.d/rc.sysinit I've checked add the contents of /fsckoptions to the $fsckoptions variable before running fsck. chattr +i makes sure nothing changes it automatically.

All of these pre-flight checks are controlled by an initial ramdisk image (initrd option in grub.conf) created by the operating system which does a quick test for errors on the filesystem and drops to single-user mode if errors are detected. Your journey for changing this behavior to run fsck -y without a password begins by decompressing the initrd image included in your kernel RPM. Unfortunately you'd likely have to do this after each system update (as redhat ships a new initrd with each kernel (or more specifically generates a new one using mkinitcpio based on your hardware)).

We have the same issue in our environment, thank you for this idea. If I get time to look into this or solve it I'll be sure to update this post.

... I think I found it. In /etc/rc.d/rc.sysinit, there's a few lines that look like:

if ! [[ " $fsckoptions" =~ " -y" ]]; then
        fsckoptions="-a $fsckoptions"
  • which, if I'm reading them correctly, add -a to the fsck options if no -y is present in $fsckoptions from earlier (a file which may not exist). I updated it a little:
if ! [[ " $fsckoptions" =~ " -y" ]]; then
        if ! [[ " $fsckoptions" =~ " -a" ]]; then
                if ! [[ " $fsckoptions" =~ " -p" ]]; then
                        fsckoptions="-y $fsckoptions"
  • that is based on the e2fsck command line: If it does not include a -y, -a, or -p, it adds -y.

Of course, the trick is testing the silly thing; I don't know how to force a file system error that would cause the normal automatic fsck to request the root password so I can know whether it actually worked or not.

  • Oh, lovely. There are version differences in /etc/rc.d/rc.sysinit. Which means while this should point you to which file to change, specific things to look for are... dicy, at best. Still, the controlling variable seems to be fsckoptions in all the versions I have found, and it seems to be sticking to being that file, so searching for fsck over & over in /etc/rc.d/rc.sysinit should lead you to the right line. The version for a 2.4 kernel image I've looked at, for instance, seems to arbitrarily add a -a to fsck, rather than checking for the presence of other types of automation first. – Robert Sep 30 '13 at 14:32

Users don't store any valuable data on their workstations, so is there a way to configure this fsck to automatically run on errors without any password ?

This is all controlled by /etc/rc.d/rc.sysinit, which is just a shell script. You could modify this to suit your needs (although you would need to be careful that your changes aren't lost in the event of a package update). Look for places where the script calls sulogin.

Reviewing this script, it looks like if you were to remove the following line:

touch /.autofsck &> /dev/null

The system would no longer run an fsck on the following boot. If you're using ext3 (or ext4), you generally won't need to run fsck.

I'm not sure how to bypass the password for that. If you are not worried about the integrity of the filesystem, you can bypass the fsck completely by appending fastboot to your kernel line in your grub.conf.

One other way around the issue: in GRUB/LILO, add init=/bin/bash to the end of the command line. This will allow you to bypass the sulogin prompt you're getting for the fsck.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.