Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 117109 - "check after next mount" incorrect and not logged
"check after next mount" incorrect and not logged
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Brock Organ
: 114277 (view as bug list)
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
Reported: 2004-02-28 12:28 EST by John Reiser
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-08 10:56:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from "tune2fs -l" on filesystem that received diagnostic (1.40 KB, text/plain)
2004-02-28 12:30 EST, John Reiser
no flags Details
output from "tune2fs -l" (2.79 KB, text/plain)
2004-03-16 22:41 EST, John Reiser
no flags Details

  None (edit)
Description John Reiser 2004-02-28 12:28:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040217

Description of problem:
During non graphical boot to level 5 (remove "rhgb" from kernel line
in grub.conf), both of the steps "Checking root filesystem" and
"Checking filesystems" report "(check after next mount)" at the end of
the "kkk/nnn blocks" line for some ext3 filesystems being mounted. 
After boot, no file in /var/log/... has any record of such a comment.
 Looking at the output of "/sbin/tune2fs -l" on the indicated
filesystems reveals no apparent cause for the message.  The  "Maximum
mount count: -1" means "never check just because of mount count".

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

How reproducible:

Steps to Reproduce:
1. Create ext3 filesystem with "Maximum mount count: -1"; enter it in
2. Boot to runlevel 5 using non-graphical boot.
3. Watch console messages during "Checking root filesystem" and
"Checking filesystems".

Actual Results:  "/home2: 823167/9781248 inodes, 12934491/19533024
blocks (check after next mount)"
appears on console, and does not appear in any /var/log/... or in
output from dmesg.

Expected Results:  "(check after next mount)" should be logged if it
appears; and should not appear if Maximum mount count is -1.

Additional info:
Comment 1 John Reiser 2004-02-28 12:30:24 EST
Created attachment 98124 [details]
output from "tune2fs -l" on filesystem that received diagnostic
Comment 2 Thomas Woerner 2004-03-15 07:24:16 EST
Fixed in rawhide in rpm e2fsprogs-1.35-7 or newer.
Comment 3 John Reiser 2004-03-16 22:34:18 EST
The symptoms persist ("check after next mount" during non-graphical
boot, for all ext3 filesystems with Maximum mount count = -1; and the
complaint is not logged anywhere in /var/log/...).  The system is
Fedora Core 2 Test 1, up2date with:

Please re-open.
Comment 4 John Reiser 2004-03-16 22:41:25 EST
Created attachment 98595 [details]
output from "tune2fs -l"

tune2fs -l output for both a root and non-root filesystem.  Both draw the
"check after next mount" diagnostic during non-graphical boot.	Both have
Maximum mount count = -1 [meaning: no check just because of mount count]; both
have Check interval = 0.  Both were checked yesterday during manual boot after
a power failure.
Comment 5 Thomas Woerner 2004-04-06 08:16:01 EDT
*** Bug 114277 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Woerner 2004-04-08 10:56:40 EDT
Fixed in rawhide in rpm e2fsprogs-1.35-7.1 or newer.

This is the correct fix - sending it upstream.
Comment 7 Alexandre Oliva 2004-04-15 23:19:50 EDT
Confirmed, thanks!

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