Bug 474705

Summary: GFS2: make gfs2_fsck conform to fsck(8) exit codes
Product: Red Hat Enterprise Linux 5 Reporter: Nate Straz <nstraz>
Component: gfs2-utilsAssignee: Robert Peterson <rpeterso>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: edamato, sghosh
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 11:02:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to fix the problem
none
Script to test the fix
none
Upstream version of the proposed patch none

Description Nate Straz 2008-12-04 21:58:29 UTC 
Description of problem:

While testing out bug 471618 I found that gfs2_fsck returned 0 after it found errors in the file system, but was not allowed to correct them.  This should have resulted in gfs2_fsck returning non-zero.  gfs2_fsck needs to return exit codes which conform to those outlined in fsck(8)

       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


Version-Release number of selected component (if applicable):
gfs2-utils-0.1.50-1.el5

How reproducible:
100%

Steps to Reproduce:
1. mkfs -t gfs -b 1024 -p lock_nolock -j 1 /dev/3T_volume
2. gfs2_convert /dev/3T_volume
3. fsck -t gfs2 -n /dev/3T_volume
  
Actual results:
...
Starting pass5
Ondisk and fsck bitmaps differ at block 137 (0x89) 
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
Bitmap at block 137 (0x89) left inconsistent
...
gfs2_fsck complete    
<pass name="gfs2_fsck" ... />


Expected results:
...
<fail name="gfs2_fsck" ... exitstatus="4"/>

Additional info:
Comment 1 Robert Peterson 2009-01-07 20:58:50 UTC 
Should be doable.
Comment 2 Robert Peterson 2009-02-10 23:11:55 UTC 
Created attachment 331496 [details]
Patch to fix the problem

This patch has been tested and found to be correct on system roth-01.
Comment 3 Robert Peterson 2009-02-10 23:23:36 UTC 
Created attachment 331499 [details]
Script to test the fix

This script tests that the proper return codes are being sent
back from gfs2_fsck under various conditions.  This script relies
upon new functions added to gfs2_edit for bug #483799.  The only
test that this script does not test is the return code caused by
interrupting the fsck.
Comment 4 Robert Peterson 2009-02-12 20:32:19 UTC 
Created attachment 331747 [details]
Upstream version of the proposed patch

This is the upstream patch I'm going to commit.
Comment 5 Robert Peterson 2009-02-12 22:54:40 UTC 
The upstream patch was committed (but I fixed two additional compiler
warnings) and pushed to the master branch of the gfs2-utils git tree.
The RHEL5 patch was pushed to the RHEL5 branch of the cluster.git tree
for inclusion into 5.4.  It was tested on system roth-01 using special
modifications to gfs2_edit for bug #483799.  Changing status to
Modified.
Comment 9 errata-xmlrpc 2009-09-02 11:02:36 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1337.html