Bug 133424 - boot-time file system check absent on xfs systems
Summary: boot-time file system check absent on xfs systems
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xfsprogs
Version: 2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-23 21:32 UTC by Richard Bonomo
Modified: 2013-07-03 02:21 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-28 16:31:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Richard Bonomo 2004-09-23 21:32:55 UTC
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 21:42:55 UTC
sounds like a problem with userspace rather than kernel.
reassigning to xfsprogs

Comment 2 Richard Bonomo 2004-11-29 21:07:21 UTC
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 05:49:40 UTC
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 06:05:14 UTC
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 15:30:19 UTC
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 16:31:23 UTC
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 21:36:12 UTC
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.