Bug 88202 - Incorrect parameters passed to fsck doesn´t permit an automatic fs recovery
Incorrect parameters passed to fsck doesn´t permit an automatic fs recovery
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-07 13:18 EDT by Avi Alkalay
Modified: 2014-03-16 22:35 EDT (History)
1 user (show)

See Also:
Fixed In Version: 7.20-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-17 12:18:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Avi Alkalay 2003-04-07 13:18:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
rc.sysinit calls:

    fsck -T -a $fsckoptions /

A better way is 

    fsck -T -a / $fsckoptions

Version-Release number of selected component (if applicable):
initscripts-6.95-1

How reproducible:
Sometimes

Steps to Reproduce:
1. turn your machine on
2. turn it off many times without a soft shutdown
3. ext3 will need a manual fsck
    

Actual Results:  3. ext3 will need a manual fsck

Expected Results:  We would like to never make a human fsck. 

Additional info:

We are using Red Hat Linux for 1700 POS (point of sale) accross the country,
being used by unskilled users that like to unsoftly shut the machine down. After
some shutdowns, rc.sysinit will ask for a manual fsck. This is unacceptable.

We used the /.autofsck mechanism to force a fsck after cold reboot, but
rc.sysinit still asks for human intervention. We then started to use the
/fsckoptions mechanism with the following content:

     -- -y

This makes fsck pass the �-y� parameter to fsck.ext2 to automatically respond
�yes�, so we don�t go into the interactive mode....

With the current rc.sysinit, fsck is called this way:

    fsck -T -a -- -y /

which fails. If the parameter order is changed as showed above, the call will be OK:

    fsck -T -a / -- -y

which works.
Using the /fsckoptions mechanism with this parameter order, ext3 never  goes
into interactive fsck, even if we turn the machine off many times in the middle
of a fsck.

This is a problem only for the / fs, because the command for the other fss is
different and OK.
Comment 1 Bill Nottingham 2003-05-02 15:58:44 EDT
Added in CVS, will be in 7.20-1. Thanks!
Comment 2 Avi Alkalay 2003-09-17 07:23:14 EDT
RHL9 still doesn't have this fix. 
Any plan to include it in RHL9 ? 
Comment 3 Bill Nottingham 2003-09-17 12:18:36 EDT
Not at this point.

Note You need to log in before you can comment on or make changes to this bug.