kernel-2.6.35.14-96.fc14.i686
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.
Thanx.
On 09/26/2011 11:59 AM, JD wrote:
kernel-2.6.35.14-96.fc14.i686
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). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - IGNORE that man behind the keyboard! - - - The Wizard of OS - ----------------------------------------------------------------------
On 09/26/2011 12:09 PM, Rick Stevens wrote:
On 09/26/2011 11:59 AM, JD wrote:
kernel-2.6.35.14-96.fc14.i686
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).
- Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
-IGNORE that man behind the keyboard! -- The Wizard of OS -
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 ]
[ -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?
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:
kernel-2.6.35.14-96.fc14.i686
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@nerd.com - - 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. - ----------------------------------------------------------------------
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:
kernel-2.6.35.14-96.fc14.i686
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.
Yes. I know that. Still no such files.
[ -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".
Yes I do have other filesystems.
About field number 6, man page says:
The sixth field, (fs_passno), is used by the fsck(8) program to deter‐ mine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.
I will set it to 0 for now, unless I run into situations, like power failure - and see if fsck gets forced.
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.
Cheers,
JD
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:
kernel-2.6.35.14-96.fc14.i686
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@nerd.com -
- 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?
------------------ 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 rc=$?
if [ "$rc" -eq "0" ]; then success "$STRING" echo elif [ "$rc" -eq "1" ]; then passed "$STRING" echo 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 fi
# A return of 4 or higher means there were serious problems. if [ $rc -gt 1 ]; then [ -n "$PLYMOUTH" ] && plymouth --hide-splash
failure "$STRING" echo echo 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 sulogin
echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" -eq "1" ]; then _RUN_QUOTACHECK=1 fi fi
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:
kernel-2.6.35.14-96.fc14.i686
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@nerd.com -
- 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 rc=$? if [ "$rc" -eq "0" ]; then success "$STRING" echo elif [ "$rc" -eq "1" ]; then passed "$STRING" echo 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 fi # A return of 4 or higher means there were serious problems. if [ $rc -gt 1 ]; then [ -n "$PLYMOUTH" ] && plymouth --hide-splash failure "$STRING" echo echo 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 sulogin echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" -eq "1" ]; then _RUN_QUOTACHECK=1 fifi
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:
kernel-2.6.35.14-96.fc14.i686
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@nerd.com -
- 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 rc=$? if [ "$rc" -eq "0" ]; then success "$STRING" echo elif [ "$rc" -eq "1" ]; then passed "$STRING" echo 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 fi # A return of 4 or higher means there were serious problems. if [ $rc -gt 1 ]; then [ -n "$PLYMOUTH" ]&& plymouth --hide-splash failure "$STRING" echo echo 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 sulogin echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" -eq "1" ]; then _RUN_QUOTACHECK=1 fifi
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 mount and there are NO partitions rom /dev/sdb mounted at all. Only / is mounted RO.
Furthermore, I manually run /etc/rc.d/rc.sysinit
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.
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: > kernel-2.6.35.14-96.fc14.i686 > > 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@nerd.com -
- 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 rc=$? if [ "$rc" -eq "0" ]; then success "$STRING" echo elif [ "$rc" -eq "1" ]; then passed "$STRING" echo 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 fi # A return of 4 or higher means there were serious problems. if [ $rc -gt 1 ]; then [ -n "$PLYMOUTH" ]&& plymouth --hide-splash failure "$STRING" echo echo 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 sulogin echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" -eq "1" ]; then _RUN_QUOTACHECK=1 fifi
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 mount and there are NO partitions rom /dev/sdb mounted at all. Only / is mounted RO.
Furthermore, I manually run /etc/rc.d/rc.sysinit
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. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Never try to outstubborn a cat. - ----------------------------------------------------------------------
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: >> kernel-2.6.35.14-96.fc14.i686 >> >> 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@nerd.com -
- 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 rc=$? if [ "$rc" -eq "0" ]; then success "$STRING" echo elif [ "$rc" -eq "1" ]; then passed "$STRING" echo 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 fi # A return of 4 or higher means there were serious problems. if [ $rc -gt 1 ]; then [ -n "$PLYMOUTH" ]&& plymouth --hide-splash failure "$STRING" echo echo 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 sulogin echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" -eq "1" ]; then _RUN_QUOTACHECK=1 fifi
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 mount and there are NO partitions rom /dev/sdb mounted at all. Only / is mounted RO.
Furthermore, I manually run /etc/rc.d/rc.sysinit
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), t0
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 !!
-
JD -
Rick Stevens