In /etc/init.d/checkroot from baselayout-1.8.6.8-r1, there's this code passage: <pre> retval=$? if [ "${retval}" -eq 0 ] then eend 0 elif [ "${retval}" -eq 1 ] then ewend 1 "Filesystem repaired" else eend 2 "Filesystem couldn't be fixed :( (${retval})" </pre> This ignores the fact that if fsck detects that the maximum mount count for / has been reached, the fs is checked and if this check yields no errors, the return value is 3. The code above interprets this as a failure, which it isn't and the machine waits there to be rebooted eventually. With a server being rebooted, this can be very, very bad. I guess the same problem exists with the maximum-time-since-last-fsck field, although I don't know what the return value would be. Same goes for /etc/init.d/checkfs Reproducible: Always Steps to Reproduce: Set the maximum mount count to 1 or the number of mounts very high, reboot the system. Actual Results: System waiting for root password ord ctrl-d, being rebooted afterwards. Expected Results: Pass of regular fsck. Maybe a nice message, too. I don't think that emerge info is necessary in this case.
This is the return values of fsck (note that if you had a return of '3', it means fsck returned codes 1 + 2 (= 3), meaning there was errors and they were corrected, and of such a nature that you need to reboot the machine. ------------------------------------ The exit code returned by fsck is the sum of the following conditions: 0 - No errors 1 - File system errors corrected 2 - System should be rebooted 4 - File system errors left uncorrected 8 - Operational error 16 - Usage or syntax error 32 - Fsck canceled by user request 128 - Shared library error
Then this probably is a bug in fsck - I run it with -v in the initscripts and it did not report any repairs - yet still exited with retval 3. Very strange. I'll do some more testing this week.
