Description of problem: There is some kind of weird regression in Fedora 21. Fedora 20 did not have this bug. With my fairly old hardware, Fedora 21 forces a full fsck on every boot. I changed broken_system_clock = 1 in /etc/e2fsck.conf but that has no effect. As a result Fedora is giving my my very old 300 GB hard drive way more wear and tear than it needs. I'm worried that Fedora 21 will kill my computer. Version-Release number of selected component (if applicable): yum updated as of today How reproducible: Always. Steps to Reproduce: 1. Reboot 2. System boot takes 25-30 minutes, fully checking the root filesystem each time. 3. Actual results: Reboot severely taxes my old 300 GB hard drive, causing every reboot to take 25-30 minutes with this type of message: Mar 05 07:20:10 localhost.localdomain systemd-fsck[278]: ROOTFS: Superblock last write time is in the future. Mar 05 07:20:10 localhost.localdomain systemd-fsck[278]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED. Mar 05 07:20:12 localhost.localdomain systemd-fsck[278]: ROOTFS: 362572/7331840 files (0.2% non-contiguous), 12431446/29304945 blocks Expected results: Reboots should take 2-3 minutes, and should not check a 250 GB root filesystem every time. Additional info: ASUS A7V8X. Had been working fine for 14 or so years. Another report of this phenomenon: http://newscentral.exsees.com/item/0a516094f59c7f58c0f707f7c81bd2b9-08374604a55e3d37e3bab27dea3a40cc
Is your hardware clock in local time (not UTC)?
I see it too, when hardware clock is in local time. When it is UTC, the file system check does not happen.
I am getting consistent systemd-fsck on my root filesystem '/'. Apr 1 23:18:06 rb11 systemd: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway. Apr 1 23:18:06 rb11 systemd: Cannot add dependency job for unit nfs.target, ignoring: Unit nfs.target failed to load: No such file or directory. Apr 1 23:18:08 rb11 systemd-fsck: /: Superblock last write time is in the future. Apr 1 23:18:08 rb11 systemd-fsck: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED. Apr 1 23:19:29 rb11 systemd-fsck: /: 257952/1281120 files (7.3% non-contiguous), 3368634/5120710 blocks I noticed the boot was taking longer in the last week and then saw fsck running. After some research I have switched between UTC and localtime, using system-config-date to set this. The fsck only occur with localtime. fsck does not run with UTC. I am on BST, time zone GMT+1 (UTC+1 I assume), and even if the machine is shutdown for more than an hour, then fsck still runs. My yum.log shows systemd was update on Mar 24, assuming this is the cause.
For my computer, this bug seems to have fixed itself with a recent update. To answer your question, I'm doing whatever Fedora Core 1 did. The computer has been continuously upgraded from one of the later versions of Red Hat Linux to Fedora Core 1 and of course today runs Fedora 21. I probably selected US/Michigan as my installation timezone 15+ years ago, but I never have deliberately selected UTC for any feature for any reason.
(In reply to John Gotts from comment #4) > For my computer, this bug seems to have fixed itself with a recent update. e2fsprogs-1.42.12-5 (rawhide), e2fsprogs-1.42.12-4 (F22, F21, F20), gained a patch to not do a full fsck when the time difference is <24h. +From f096708126412c0569e40cfbd5740729976bf12a Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o <tytso> +Date: Sat, 28 Mar 2015 21:39:54 -0400 +Subject: e2fsck: use PROMPT_NONE for FUTURE_SB_LAST_*_FUDGED problems + +This allows us to print a message warning the user that there is +something funny going on with their hardware clock (probably time zone +issues caused by trying to be compatible with legacy OS's such as +Windows), without triggering a full file system check. + +Signed-off-by: Theodore Ts'o <tytso> > To answer your question, I'm doing whatever Fedora Core 1 did. Impressive :)
There is no e2fsprogs-1.42.12-4 update for F22.
It is not yet in updates-testing. https://admin.fedoraproject.org/updates/e2fsprogs-1.42.12-4.fc22 fixes the issue for me.
*** This bug has been marked as a duplicate of bug 1202024 ***