Bug 240545

Summary: gfs2_fsck should behave more like the other fscks.
Product: Red Hat Enterprise Linux 5 Reporter: Steve Whitehouse <swhiteho>
Component: gfs2-utilsAssignee: Chris Feist <cfeist>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0350 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 17:19:57 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:
Bug Depends On: 286211    
Bug Blocks:    
Attachments:
Description Flags
Proposed patch to fix the problem
none
Addendum patch
none
Addendum patch revised none

Description Steve Whitehouse 2007-05-18 12:36:47 UTC
This bug is largely so I don't forget about it, but a couple of things occured
to me about fsck which should really be addressed at some stage:

1. The question asking code shouldn't require a <return> after asking a y/n
question so that its compatible with other fsck question asking interfaces.

2. Is there any reason we cannot rename the binary to fsck.gfs2 like all the
other filesystems? Obviously we need backwards compatibility, but a symlink in
the packaging should deal with that.

Comment 1 Robert Peterson 2007-05-18 14:23:59 UTC
1. Should be easy.
2. Should be easy.

I'd like to add #3:

When I made the changes to allow SIGINT to be caught and to ask the user
if he/she wants to skip the current pass, I got into a bind whereby
if you interrupt it while a question is being asked, it does not
re-ask the question, so the user may be left confused.  My solution at the
time was to ignore the interrupt while it's asking any Y/N questions.
The problem with that is obvious: If there is a massive amount of
fs corruption, it will keep asking annoying questions and never let
the user break out of it.  Unless, of course, they go to another
terminal cli and use the kill command.  That's bad because sometimes 
they may just want to get out and restart it with the -y option.
Shouldn't be too difficult, but not quite as easy as #1 and #2.

So #3: Allow <ctrl-c> interrupts to be processed in a friendly
manner while a Y/N question is being asked.


Comment 2 Robert Peterson 2007-08-07 15:58:05 UTC
Created attachment 160826 [details]
Proposed patch to fix the problem

This patch has been tested on system trin-10 by manually answering
questions with a single character (no enter), interrupting the various
passes, and interrupting the questions.

Comment 3 Robert Peterson 2007-08-15 21:20:38 UTC
I posted the proposed fix to cluster-devel on 08 August 2007.
Nobody commented on the proposed patch so I'm assuming it's good to
go for RHEL5.2.


Comment 4 Robert Peterson 2007-08-15 22:34:04 UTC
Tested on system trin-10.  Committed to cvs in HEAD and RHEL5 branches.
Changing status to Modified.


Comment 5 Rob Kenna 2007-09-11 15:57:04 UTC
splitting out bug 286211: gfs2_fsck not found by fsck wrapper

Comment 6 Robert Peterson 2007-10-11 15:23:59 UTC
Discovered a small problem with this fix.  Need a modify it slightly.
Resetting to assigned state, since it hasn't been built yet and still
doesn't have the right ack flags at this time.


Comment 7 Robert Peterson 2007-10-11 16:04:50 UTC
Created attachment 224531 [details]
Addendum patch

This addendum patch fixes the problem mentioned in comment #6.

Comment 8 Robert Peterson 2007-10-11 16:29:27 UTC
Created attachment 224551 [details]
Addendum patch revised

Fixed a stupid bug in the previous addendum patch.

Comment 9 Robert Peterson 2007-10-11 16:36:59 UTC
Fix tested on roth-01 then committed to HEAD and RHEL5 branches for
inclusion in 5.2.  Setting back to modified state.


Comment 12 errata-xmlrpc 2008-05-21 17:19:57 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 the 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/RHBA-2008-0350.html