Red Hat Bugzilla – Bug 117109
"check after next mount" incorrect and not logged
Last modified: 2007-11-30 17:10:37 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):
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
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.
Created attachment 98124 [details]
output from "tune2fs -l" on filesystem that received diagnostic
Fixed in rawhide in rpm e2fsprogs-1.35-7 or newer.
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:
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.
*** Bug 114277 has been marked as a duplicate of this bug. ***
Fixed in rawhide in rpm e2fsprogs-1.35-7.1 or newer.
This is the correct fix - sending it upstream.