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 ?
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"
fi
if ! [[ " $fsckoptions" =~ " -y" ]]; then
if ! [[ " $fsckoptions" =~ " -a" ]]; then
if ! [[ " $fsckoptions" =~ " -p" ]]; then
fsckoptions="-y $fsckoptions"
fi
fi
fi
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.
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.
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.
