Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 117109 - "check after next mount" incorrect and not logged
Summary: "check after next mount" incorrect and not logged
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Brock Organ
URL:
Whiteboard:
: 114277 (view as bug list)
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
 
Reported: 2004-02-28 17:28 UTC by John Reiser
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-04-08 14:56:40 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
output from "tune2fs -l" on filesystem that received diagnostic (deleted)
2004-02-28 17:30 UTC, John Reiser 		no flags Details
output from "tune2fs -l" (deleted)
2004-03-17 03:41 UTC, John Reiser 		no flags Details
View All

Description John Reiser 2004-02-28 17:28:42 UTC 
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):
initscripts-7.46-1.1

How reproducible:
Always

Steps to Reproduce:
1. Create ext3 filesystem with "Maximum mount count: -1"; enter it in
/etc/fstab.
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 17:30:24 UTC 
Created attachment 98124 [details]
output from "tune2fs -l" on filesystem that received diagnostic
Comment 2 Thomas Woerner 2004-03-15 12:24:16 UTC 
Fixed in rawhide in rpm e2fsprogs-1.35-7 or newer.
Comment 3 John Reiser 2004-03-17 03:34:18 UTC 
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:
  e2fsprogs-1.35-7
  e2fsprogs-devel-1.35-7
  initscripts-7.46-1.1
  SysVinit-2.85-20
  kernel-2.6.3-2.1.253

Please re-open.
Comment 4 John Reiser 2004-03-17 03:41:25 UTC 
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 12:16:01 UTC 
*** Bug 114277 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Woerner 2004-04-08 14:56:40 UTC 
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-16 03:19:50 UTC 
Confirmed, thanks!
Note You need to log in before you can comment on or make changes to this bug.