Re: fsck exits with error status, even though no errors are found

On 09/26/2011 06:49 PM, Rick Stevens wrote:
On 09/26/2011 06:29 PM, JD wrote:
On 09/26/2011 06:07 PM, Rick Stevens wrote:
On 09/26/2011 05:55 PM, JD wrote:
On 09/26/2011 01:49 PM, Rick Stevens wrote:
On 09/26/2011 01:25 PM, JD wrote:
On 09/26/2011 12:09 PM, Rick Stevens wrote:
On 09/26/2011 11:59 AM, JD wrote:

During boot, when the time comes for fsck'ing
the file systems, whatever script is doing that,
is exiting with an error status, even though no
errors are displayed, and I am prompted to either
enter the root password, or type Contrl-D to continue.
Cntrl-D simply reboots. Entering the root password,
and running fsck manually to check all filesystems in fstab,
yields that all is well, no errors are found, and the exit
status is 0.

Would appreciate some info on identifying the script that
does the fsck during boot.
/etc/rc.d/rc.sysinit is the guy and it'll force an fsck if it sees
a file called "/forcefsck" or "/.autofsck" in the root of the
filesystem or if there's a "forcefsck" on the command line of the kernel
(check your /etc/grub/grub.conf file).
Thanks Rick.

I checked /etc/rc.d/rc.sysinit
and I see that it does check for the presence of files like:

if [ -f /fsckoptions ]

if [ -f /forcefsck ]

elif [ -f /.autofsck ]
Remember you need the "-a" option to ls to see files that begin with a
dot, e.g. "ls -a /.autofsck". Just making sure.

[ -f /etc/sysconfig/autofsck ]

and I have none of these files.

I checked /boot/grub/grub.conf and I see
no presence of any string like fsck or force
or auto in it.

The only script I found that invokes /etc/rc.d/rc.sysinit is
/etc/init/rcS.conf, and it is not passing any args to it.

I wounder if this maybe a bash problem?
Do you have other filesystems on other partitions that might be
triggering this? Check your /etc/fstab file and see if any entries
have stuff other than "0" as the last field. Generally, "/" should
have a "1" as the last field, "/boot" should have a "2", the rest (if
any) should have "0".

Also note that the system may force an fsck if you've exceeded the
"mounts between fsck runs" or "interval-between-checks" set on ext2/3/4
filesystems (and others, I think) via the "tune2fs -c" or "tune2fs -i"
commands. You could run "tune2fs -l" on the block device holding your
root filesystem to see what values are set currently.

Just an idea.
- Rick Stevens, Systems Engineer, C2 Hosting ricks@xxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- First Law of Work: -
- If you can't get it done in the first 24 hours, work nights. -
If this helps any, I instrumented /etc/rc.d/rc.sysinit
and added to it to print the full fsck command being issued
and the value of the exit status of fsck.
Well, here's what my instrumentation printed:

fsck -T -t noopts=_netdev -A $fsckoptions<<<<<
rc = 16<<<<<

return value of 16? And yet no fsck problems of any kind??

So is this an fsck bug??
Has anyone else come across this?
Error 16 is "EBUSY", which leads one to believe that SOMETHING that's
being fsck'd isn't there or hasn't spun up or something.

------------------ excerpt from /etc/rc.d/rc.sysinit--------------------

if [ -z "$fastboot" -a "$READONLY" != "yes" ]; then

STRING=$"Checking filesystems"
echo $STRING
fsck -T -t noopts=_netdev -A $fsckoptions

if [ "$rc" -eq "0" ]; then
success "$STRING"
elif [ "$rc" -eq "1" ]; then
passed "$STRING"
elif [ "$rc" -eq "2" -o "$rc" -eq "3" ]; then
echo $"Unmounting file systems"
umount -a
mount -n -o remount,ro /
echo $"Automatic reboot in progress."
reboot -f

# A return of 4 or higher means there were serious problems.
if [ $rc -gt 1 ]; then
[ -n "$PLYMOUTH" ]&& plymouth --hide-splash

failure "$STRING"
echo $"*** An error occurred during the file system check."
echo $"*** Dropping you to a shell; the system will reboot"
echo $"*** when you leave the shell."

str=$"(Repair filesystem)"
PS1="$str \# # "; export PS1
[ "$SELINUX_STATE" = "1" ]&& disable_selinux

echo $"Unmounting file systems"
umount -a
mount -n -o remount,ro /
echo $"Automatic reboot in progress."
reboot -f
elif [ "$rc" -eq "1" ]; then

Well, this is a new behavior.
I only have one internal disk (dual boot)
and one external disk (5 GPT partitions),
and when any of those partitions is being fsck'ed
at boot, fsck says it is in good shape.
I do not see anything about a partition being
either busy or already opened or already mounted.
In fact, when I am prompted to enter control-D
or provide root password, I type the password
and run
and there are NO partitions rom /dev/sdb mounted at all.
Only / is mounted RO.

Furthermore, I manually run

and it passes with flying colors.

So, something's going on at boot time that
is not being encountered when the script
is run manually.
Also, I do not powerdown the external drive,
and neither the internal drive (obviously),
and I simply type reboot.
At reboot, the same scenario of failed fsck
with errno 16.
My bad. EBUSY is errno 16, but according to fsck's info page, a return
code of 16 is "Usage or syntax error", so it's not something not
spinning up, but something in the command line is fubar'd. You might
try adding

echo "fsck -T -t noopts=_netdev -A $fsckoptions"

just before the actual call to fsck to see exactly how fsck is being
called. I suspect something's rotten in the $fsckoptions parameter.
Hi Rick,
I modified the fsck command (After I saved the original script),

fsck -p

That's it! No other options.

fsck man page says that the -a option is mapped onto the -p option,
and is there only for legacy compatibility.

And fsck still exits with errno 16 !!

users mailing list
To unsubscribe or change subscription options: