Mike Lincoln wrote:
Hello all,
        I believe I have found (and fixed) a trivial bug in checkfs, but that's
not the reason for this email. I was about to file it with bugzilla and
I found something quite strange.

First off the bug:

/etc/init.d/checkfs v1.29 incorrectly tests the return code from fsck
at line 201.



elif [ "${retval}" -gt 1 -a "${retval}" -lt 4 ]
        then
                ewend 1 "Filesystem errors corrected."
                # Everything should be ok, so return a pass
                return 0
        else


Should, IMHO, read:


elif [ "${retval}" -ge 1 -a "${retval}" -lt 4 ]
        then
                ewend 1 "Filesystem errors corrected."
                # Everything should be ok, so return a pass
                return 0
        else


Note the -gt goes to -ge because fsck returns 1 on corrected errors. BTW. I discovered this with a jfs root file system. This is because
fsck.jfs alway seems to return 1 when it replays the log. I guess
that's a feature looking at the man page.

From man fsck, the exit codes of fsck are as follows:


            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

From that, it seems that 0, 1, and possibly 2 and 32 are acceptable, but to make the acceptable values clearer (and easier if 32 is allowed) we might consider changing the elif to:

elif [ $((retval & ~(0|1|2|32))) -eq 0 ]

That more clearly indicates that 0, 1, and 2 (or combinations thereof) are accepted values, but anything else is not. It also allows us to add, for example, 32, which IMHO seems like it should be allowed as well. Yes, it isn't known that the filesystem is okay, but if I user really wants to cancel it, they can. Additionally, 64 is currently not defined - if it became something like "non-critical filesystem errors left uncorrected", it'd be trivial to add.

Now for the odditie: I have two gentoo boxes, both have recently run
"emerge sync && emerge baselayout". I've double checked and both boxes
have the same version of baselayout. /However/, they have different
versions of checkfs! I've reemerged baselayout on both machines, but
they still have different versions of checkfs 1.23 and 1.29.

At a guess, I'd say the updated files are pending due to config protection, and you haven't merged them yet with etc-update?


--
-- Jason Rhinelander
-- Gossamer Threads, Inc.


-- [EMAIL PROTECTED] mailing list



Reply via email to