fsck does not work after a reboot if the date from Next check after: is in the past. Version-Release number of selected component (if applicable): util-linux-2.23.2-5.fc19.x86_64 How reproducible: Steps to Reproduce: 1. Set Next check after on tomorrow 2. Wait for to days 3. Reboor your system Actual results: There will be no forced fsck. The date form Next check after: will not change. Expected results: A forced file system check. Additional info: I just rebooted my system and below the output from tune2fs. The mount count and max mount count work properly. [root@bhw325 ~]# tune2fs -l /dev/sdb1 tune2fs 1.42.7 (21-Jan-2013) Filesystem volume name: nobackup Last mounted on: /nobackup Filesystem UUID: 1c77ffbc-45d6-4607-b45b-098e1ec6889e Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 91578368 Block count: 366284288 Reserved block count: 18314214 Free blocks: 41567504 Free inodes: 91004396 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 936 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Fri Dec 17 10:31:08 2010 Last mount time: Mon Nov 24 07:59:03 2014 Last write time: Mon Nov 24 07:59:03 2014 Mount count: 7 Maximum mount count: -1 Last checked: Wed Nov 19 12:35:27 2014 Check interval: 86400 (1 day) Next check after: Thu Nov 20 12:35:27 2014 Lifetime writes: 2122 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 08ed0e71-b73f-42ca-818d-92788d71356e Journal backup: inode blocks
What version of e2fsprogs?
e2fsprogs-1.42.7-2.fc19.x86_64
It seems to work here, how have you determined that it doesn't work? # dumpe2fs -h pastdate.img | grep check Last checked: Thu Nov 20 10:19:22 2014 Next check after: Fri Nov 21 10:19:22 2014 # date Mon Nov 24 10:21:09 CST 2014 # e2fsck/e2fsck -p pastdate.img pastdate.img has gone 4 days without being checked, check forced. pastdate.img: 11/32768 files (0.0% non-contiguous), 9787/131072 blocks # e2fsck/e2fsck -V e2fsck 1.42.7 (21-Jan-2013) Using EXT2FS Library version 1.42.7, 21-Jan-2013 -Eric
Or if you prefer, w/o -p: # e2fsck/e2fsck pastdate.img e2fsck 1.42.7 (21-Jan-2013) pastdate.img has gone 4 days without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information pastdate.img: 11/32768 files (0.0% non-contiguous), 9787/131072 blocks
Re: It seems to work here, how have you determined that it doesn't work? [root@xxxxxx ~]# dumpe2fs -h /dev/sdb1|grep check dumpe2fs 1.42.7 (21-Jan-2013) Last checked: Wed Nov 19 12:35:27 2014 Next check after: Thu Nov 20 12:35:27 2014 [root@bhw325 ~]# date Mon Nov 24 16:46:19 GMT 2014 [root@xxxxxx ~]# e2fsck -p /dev/sdb1 nobackup: clean, 573973/91578368 files, 326120949/366284288 blocks [root@xxxxxx ~]# dumpe2fs -h /dev/sdb1|grep check dumpe2fs 1.42.7 (21-Jan-2013) Last checked: Wed Nov 19 12:35:27 2014 Next check after: Thu Nov 20 12:35:27 2014 [root@xxxxxx ~]#
Well that's odd, isn't it. Let me actually get a proper F19 box provisioned and take a look. -Eric
Oh, ok - hohum, it's this in /etc/e2fsck.conf, which I'd forgotten about. # cat /etc/e2fsck.conf [options] # This will prevent e2fsck from stopping boot just because the clock is wrong broken_system_clock = 1 I thought that was smart enough to only ignore seriously mangled system times. I'll have to go back & remember why we had this, and most likely remove it. Perhaps accept_time_fudge would be better middle ground, though I'll have to re-remember how this is all supposed to work. For now, just comment that line out and you'll get the behavior you expect. -Eric
Hello Eric Commenting out the line did the job. The filesystem check works now. Thanks Leo
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still need to fix this, but it's also a dup of another bug, so doing that. *** This bug has been marked as a duplicate of bug 963283 ***