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 2CF021384ED for ; Wed, 16 Jan 2013 19:36:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1213121C117; Wed, 16 Jan 2013 19:36:33 +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 5B8D621C09D for ; Wed, 16 Jan 2013 19:36:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8104C33D990 for ; Wed, 16 Jan 2013 19:36:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5.5 tests=[AWL=-2.466, 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 BnHYGJ_ucG_p for ; Wed, 16 Jan 2013 19:36:24 +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 A8DEA33DA19 for ; Wed, 16 Jan 2013 19:36:22 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TvYmp-0002lm-MO for gentoo-user@gentoo.org; Wed, 16 Jan 2013 20:36:35 +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 ; Wed, 16 Jan 2013 20:36:35 +0100 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Jan 2013 20:36:35 +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: Wed, 16 Jan 2013 19:36:07 +0000 (UTC) Message-ID: References: <20130116175249.GE2656@server> 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: 22f7ebc7-098f-4a9b-b01f-58bbc164af31 X-Archives-Hash: 916c1603331f81381a80384973853552 On 2013-01-16, Bruce Hill wrote: > On Wed, Jan 16, 2013 at 04:43:16PM +0000, 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. >> >> Just to make it extra convenient, it clears the console screen when >> that happens so there's no actual record of what went wrong or which >> component in th init process is failing. >> >> Going into the BIOS setup and setting the time ahead a minute or two >> will allow the system to start up normally. >> >> Is there any way to disable this "feature"? > > Replace your CMOS battery. I'll try that. I enabled init logging and did more testing, and I now don't think it's actually the motherboard clock that's causing the problem. It seems that a second reboot without changing the clock usually fixes the problem also. I have had systems in the past who refused to boot because the motherboard time was off, and at first it looked like that was the problem again. > Default behavior of agetty is to clear now. In /etc/inittab make sure you have > --noclear in tty1 like this: Yup, figured that one out once I realized that in the normal case it's agetty rather than the init system itself that clears the screen. But, in the failures I've been seeing today, it's not getting to agetty. The "clear screen and halt" happens at the "waiting for udev events" step... -- Grant Edwards grant.b.edwards Yow! You should all JUMP at UP AND DOWN for TWO HOURS gmail.com while I decide on a NEW CAREER!!