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@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 >> 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 >> > 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. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
