Bug 577126 - Mount time check at boot makes system too fragile, and is not handled well
Mount time check at boot makes system too fragile, and is not handled well
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
: 582396 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-26 05:06 EDT by Ed Avis
Modified: 2010-10-21 19:06 EDT (History)
6 users (show)

See Also:
Fixed In Version: e2fsprogs-1.41.10-7.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-08 14:15:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ed Avis 2010-03-26 05:06:52 EDT
(Although I have filed this under component e2fsprogs, it is really a bug against the Fedora distribution as a whole.)

If the real-time clock on a system malfunctions then it may report the current date as 2005 or some other time far in the past.  This means that when the Fedora system is booted, it will drop into a text console and require logging in with the root password and manual fsck to get it working.

The same happens if a user sets the date (whether from Linux or some other operating system) and reboots into Fedora.  I believe it could also happen if the date is changed in Fedora and the machine is power-cycled immediately afterwards.

I would like to suggest that this makes the system too fragile, and that 'mount time in the future', which is not in itself a dangerous filesystem error, be handed in a more gentle way.  It shouldn't abort the whole startup process and require manual fsck, which non-technical users have no idea how to do.

One answer might be to mount the filesystem and continue booting anyway, but to prompt the user on login to check the date and time are correct.
Comment 1 Eric Sandeen 2010-03-26 13:51:13 EDT
There is now a bit more slop available for this:

        /*
         * Check to see if the superblock last mount time or last
         * write time is in the future.
         */
        if (fs->super->s_mtime > (__u32) ctx->now) {
                pctx.num = fs->super->s_mtime;
                problem = PR_0_FUTURE_SB_LAST_MOUNT;
                if (fs->super->s_mtime <= (__u32) ctx->now + ctx->time_fudge)
                        problem = PR_0_FUTURE_SB_LAST_MOUNT_FUDGED;
                if (fix_problem(ctx, problem, &pctx)) {
                        fs->super->s_mtime = ctx->now;
                        ext2fs_mark_super_dirty(fs);
                }
        }

from:

commit ba5131f6d48eded504e84c2a8ffc8131df8a512e
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Oct 16 20:46:45 2009 -0400

    e2fsck: Accept superblock times to be fudged by up to 24 hours by default

but you're right, a clock set to 2005 will still trip this up.  To be honest, I'm not certain why e2fsck cares about this so much.

e2fsprogs is the right place for this bug, this behavior is unique to e2fsck AFAIK.

-Eric
Comment 2 Eric Sandeen 2010-05-14 12:09:42 EDT
*** Bug 582396 has been marked as a duplicate of this bug. ***
Comment 3 Eric Sandeen 2010-05-14 12:13:53 EDT
There's another fix upstream which will help in most of these situations:

From: Theodore Ts'o <tytso@mit.edu>
Date: Thu, 13 May 2010 21:36:36 +0000 (-0400)
Subject: e2fsck: Skip time-based checks if the time looks insane or broken_system_clock
X-Git-Url: http://git.kernel.org/?p=fs%2Fext2%2Fe2fsprogs.git;a=commitdiff_plain;h=177839e2454dcc298244481da9c72a19b41836be

e2fsck: Skip time-based checks if the time looks insane or broken_system_clock

There are broken embedded devices that have system clocks that always
reset to January 1, 1970 whenever they boot (even if no power is
lost).  There are also systems that have super cheap clock crystals
that can be very inaccurate.  So if the option broken_system_clock is
given, disable all time based checks.  E2fsck will also try to detect
incorrect system clock times, and automatically mark the system clock
as insane.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---

The fix basically turns off time-based checks if the clock claims to be prior to Jan 1, 2010.
Comment 4 Eric Sandeen 2010-07-05 16:11:43 EDT
I think the 2 commits mentioned above will mitigate most of the problems here.

I'll merge the fix into F12 and F13 if needed.
Comment 5 Fedora Update System 2010-07-05 16:55:34 EDT
e2fsprogs-1.41.10-7.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/e2fsprogs-1.41.10-7.fc13
Comment 6 Fedora Update System 2010-07-05 16:56:33 EDT
e2fsprogs-1.41.9-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/e2fsprogs-1.41.9-8.fc12
Comment 7 Eric Sandeen 2010-07-05 16:57:09 EDT
Ok, built in these patches for F12 & F13, should be in testing shortly.
Comment 8 Fedora Update System 2010-07-06 13:11:58 EDT
e2fsprogs-1.41.9-8.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update e2fsprogs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/e2fsprogs-1.41.9-8.fc12
Comment 9 Fedora Update System 2010-07-06 13:18:04 EDT
e2fsprogs-1.41.10-7.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update e2fsprogs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/e2fsprogs-1.41.10-7.fc13
Comment 10 Fedora Update System 2010-07-08 14:15:21 EDT
e2fsprogs-1.41.10-7.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

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