Showing results for 
Search instead for 
Did you mean: 

Redhat fsck

New Member

Redhat fsck

We have a RH virtual machine that we had to reboot. It has approx 5.5tb of staorage attached via an IOMEGA NAS drive.
As the system hadn't rebooted in over 190 days, it's running and fsck - and taking forever, 5 hours so far, and we estimate we're about 25% complete.
Is there any safe way to reboot and bypass the fsck. I'm assuming we would need to get to something like "single user mode" and edit the fstab file.
Has anyone any ideas on how best to proceed?

Many thanks,
Honored Contributor

Re: Redhat fsck

last field in /etc/fstab is for fsck, if I'm correct. Setting "0" there means no fsck needed during boot time. Usually no need to get to single user unless it is some system mount (i.e. /usr , /var etc). "fuser" will show you who uses the mountpoint.
So computers don't think yet. At least not chess computers. - Seymour Cray
Honored Contributor

Re: Redhat fsck

You did not specify the filesystem type, but I assume you're using ext3 filesystems, as it's the RedHat default...

To disable automatic filesystem checks based on number of mounts and time since last full check, you can use this command:

tune2fs -c 0 -i 0 /dev/

With this modification, the system will still run the journal recovery process at every boot-time fsck (which should be fast) and if a filesystem error was detected when the filesystem was used the last time, a full fsck will be performed (which will be exactly as slow as what you're now experiencing).

Is this the root filesystem or a separate data filesystem? If it's the root filesystem, editing /etc/fstab may have no effect, since the root filesystem is treated specially. The tune2fs command I specified above should still be effective.

Interrupting the fsck on a VM may be tricky. Too bad you did not specify your virtualization method - VMware, RedHat Xen, or something else?
Essentially, if you have a method to send the equivalent of a Ctrl-Alt-Del keypress to the VM, that should be a reasonably safe way to interrupt the boot process.

If this is the root filesystem, the standard boot to single user mode (using the kernel boot option "single") may be too late, as the boot process may check & mount the root filesystem before it presents the single-user mode command prompt. In that case, the boot option "init=/bin/bash" should work: it interrupts the boot process a bit earlier, leaving the root filesystem in read-only mode and all the other filesystems completely unmounted.

If you use "init=/bin/bash", your first steps should be:
mount /proc
mount -o remount,rw /

After that, remember that you will be in an extreme bare-bones environment: even the PATH variable may not include all the things you've come to expect by default.