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:
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:
All versions of
/etc/rc.d/rc.sysinit
I've checked add the contents of/fsckoptions
to the$fsckoptions
variable before runningfsck
.chattr +i
makes sure nothing changes it automatically.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 callssulogin
.Reviewing this script, it looks like if you were to remove the following line:
The system would no longer run an fsck on the following boot. If you're using
ext3
(orext4
), 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.