From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DFB7E138522 for ; Thu, 17 Jan 2013 22:48:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 068E721C0CB; Thu, 17 Jan 2013 22:47:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6693221C04A for ; Thu, 17 Jan 2013 22:47:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 87D0133DAF0 for ; Thu, 17 Jan 2013 22:47:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5.5 tests=[AWL=-2.462, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jioEE3xzCiCV for ; Thu, 17 Jan 2013 22:47:37 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id ECD4C33DA49 for ; Thu, 17 Jan 2013 22:47:34 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TvyFO-0000Ev-TF for gentoo-user@gentoo.org; Thu, 17 Jan 2013 23:47:46 +0100 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Jan 2013 23:47:46 +0100 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Jan 2013 23:47:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: System won't boot if CMOS clock is slow Date: Thu, 17 Jan 2013 22:47:17 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dsl.comtrol.com User-Agent: slrn/1.0.1 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: 9c97a237-f82f-4d03-9a24-2371f6486298 X-Archives-Hash: 58dc738221f5fd1afbd95a0007991adb On 2013-01-17, Stroller wrote: > > On 16 January 2013, at 16:43, Grant Edwards wrote: > >> I'm having problems with one of my Gentoo systems who's motherboard >> clock is a little slow. When the system comes up, the system time is >> set from the motherboard clock. If that's slow, something in the init >> system seems to panic because some file or other has a timestamp in >> the future. > > You've had lots of other suggestions here, but I think this is > handled fine if you add ntp to the default runlevel (and assuming the > system can connect to the net). It doesn't help problems that occur before ntpd has started and had a chance to slew the clock. By default, ntpd doesn't seem to want to do a step correction to fix large clock errors on startup (there's probably an option for that). FWIW, I recently identified one rather obscure CMOS-clock-related problem scenario (this isn't what happened the other day, but it did waste about half a day a few months back): 1) Your CMOS clock is ahead of the "real" time by several hours for some reason. There are a number of ways this can happen: dual-booting between systems that disagree over UTC vs localtime for the CMOS clock, broken ntpd config, mismanaged timezone settings, etc. 2) Kernel comes up and sets system time from CMOS clock. 3) Root filesystem gets fsck'ed because it's been mounted 28 times, and filesystem meta-data gets timestamp that is actually several hours in the future. 4) System reboots after fsck is finished. 5) Before the recently fsck'ed filesystem gets mounted, the CMOS clock gets reset to the correct time (by dual booting, booting from a rescue CD, or by simply running the BIOS setup and fixing it). 6) The system boots again, and when it tries to mount the root filesystem, the filesystem meta-data has a timestamp that's in the future so the ext3 code in the kernel refuses to mount it. 7) You futz around verifying that you have a good root fs backup, looking at S.M.A.R.T logs and all sorts of other irrelevant things for several hours trying to figure out what's wrong. 8) The universe catches up to the filesystem meta-data timestamp, and suddenly, mysteriously, everything works fine. -- Grant Edwards grant.b.edwards Yow! You mean you don't at want to watch WRESTLING gmail.com from ATLANTA?