Bug 133424 - boot-time file system check absent on xfs systems
boot-time file system check absent on xfs systems
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xfsprogs (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-23 17:32 EDT by Richard Bonomo
Modified: 2013-07-02 22:21 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-28 12:31:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Richard Bonomo 2004-09-23 17:32:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.8.2 (KHTML, like Gecko) Safari/85

Description of problem:
When the boot script gets to the point, after a bad shutdown, at which it gives the
operator a chance to choose to run a file-system check, selecting the check does
nothing.  I suspect the problem is that the boot-time file-system check simply
is not set up for xfs systems....

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


How reproducible:
Always

Steps to Reproduce:
1. reboot system after (all too frequent) bad shutdowns
2.
3.
    

Actual Results:  The system fails to do the file-system check, even though when it is supposedly "forced"

Expected Results:  It should do the file system check.

Additional info:

All disk drives are xfs.
Comment 1 Dave Jones 2004-11-27 16:42:55 EST
sounds like a problem with userspace rather than kernel.
reassigning to xfsprogs
Comment 2 Richard Bonomo 2004-11-29 16:07:21 EST
It may be userspace rather than kernel.  I suspect the problem lies in whatever summons the
file check software after a "bad" shutdown and reboot: it may not be "smart" enough to
to inquire as to the file system in use before invoking file check software.  As it does not appear
to be a problem with xfsprogs per se (though I could be wrong), I assigned this to kernel
rather than xfsprogs.

Rich
Comment 3 Barry K. Nathan 2005-02-06 00:49:40 EST
It's definitely not the kernel. It could be xfsprogs. It could be
initscripts.

I've seen this problem on Mandrake 10.0/10.1 as well, so I don't think
it's Red Hat-specific.

I'll see if I can narrow this down tonight...
Comment 4 Barry K. Nathan 2005-02-06 01:05:14 EST
Run "man fsck.xfs" and look at the output... It looks like this is
documented and intentional upstream xfsprogs behavior. I think I
actually knew that in the past, but I had forgotten.
Comment 5 Matthew Miller 2005-04-26 11:30:19 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 6 John Thacker 2006-10-28 12:31:23 EDT
Closing per lack of response.  Also note that FC1 and FC2 are no longer
supported even by Fedora Legacy.  If this still occurs on FC3 or FC4, please
assign to that version and Fedora Legacy.  If it still occurs on FC5 or FC6,
please reopen and assign to the correct version.

Also, previous comments suggest that this is intentional upstream behavior.
Comment 7 Richard Bonomo 2006-11-01 16:36:12 EST
Somehow I missed Barry Nathan's comment about running man fsck.xfs.  I just tried it on the server
(now running FC4) and it reports that it is a null utility.

I am not sure what is meant my "intentional upstream behavior"  FC2 supports/ed xfs, so it 
seems only natural that it would be able to check xfs systems at boot time.  I suspect that FC4 will
act the same way, but I have not yet been able to test that.

If I can, and the same behavior occurs, I will re-assing this to FC4.

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