From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot) Date: Mon, 04 Jan 2016 16:02:00 +0100 Message-ID: <87r3hxbd7b.fsf@gnu.org> References: <87ege42bg6.fsf@dustycloud.org> <87oad5jp4e.fsf@gnu.org> <87io3aypk7.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG6f2-0006IC-O2 for bug-guix@gnu.org; Mon, 04 Jan 2016 10:03:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG6f0-0002pU-0v for bug-guix@gnu.org; Mon, 04 Jan 2016 10:03:04 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:49466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG6ez-0002pQ-Tz for bug-guix@gnu.org; Mon, 04 Jan 2016 10:03:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aG6ez-0004gP-Nk for bug-guix@gnu.org; Mon, 04 Jan 2016 10:03:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87io3aypk7.fsf@dustycloud.org> (Christopher Allan Webber's message of "Sun, 03 Jan 2016 21:39:35 -0600") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Christopher Allan Webber Cc: 22274@debbugs.gnu.org Christopher Allan Webber skribis: > Ludovic Court=C3=A8s writes: > >> Christopher Allan Webber skribis: >> >>> If I reboot into GuixSD, at some point in the boot process it resets my >>> hardware clock to 1970! If I reboot into Debian again after that, it's >>> 1970 there also. >> >> Ouch! Your config includes the ntp daemon. Could it be that it=E2=80= =99s >> misbehaving? >> >> You can remove it along the lines of: >> >> (define %my-desktop-services >> (remove (lambda (service) >> (eq? (service-kind service) ntp-service-type)) >> %desktop-services)) >> >> Well, you need to export =E2=80=98ntp-service-type=E2=80=99 from (gnu se= rvices >> networking) first=E2=80=A6 >> >> Other than that, I have no idea what could be resetting the hardware >> clock to 0. > > So I did this, and it stopped resetting the hardware clock for Debian as > well when I rebooted into Guix. Could you check in /var/log/messages or nearby if there were relevant messages from ntpd? I wouldn=E2=80=99t expect it to reset the date. I always run it on my lapt= op, and nothing ever went havoc, whether or not networking access was available. > It also makes me think that there's no reason we should have > ntp-service-type in %desktop-services, though that's a separate issue. Maybe, I=E2=80=99m open to discussion. My impression is that it=E2=80=99s = =E2=80=9Cusually=E2=80=9D enabled by default on desktop distros. Then again I=E2=80=99ve been told t= hat tlsdate would be sufficient and safer. > So that's part 1 resolved, I think. Part 2 is the problem that even > though Debian now keeps the right time while rebooting from Debian -> > GuixSD -> Debian, GuixSD still doesn't know what time it is... or that > is, doesn't know what time it is on the most recent system build! It > turns out my 0.9.0 system build still works correctly. Weird. > Not only that, but I verified that my friend Aeva hits the *same* > "problem" and "solution"...! Same hardware? > *** Most recent Guix system (Linux-Libre 4.3.3) *** > > bash-4.3$ date > Wed Dec 31 18:01:42 CST 1969 > bash-4.3$ sudo hwclock -r > hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid = argument Anything in /var/log/messages, tty12, or similar? Could it be a driver issue? Works for me (a Dell laptop) with recentish GuixSD: --8<---------------cut here---------------start------------->8--- $ sudo hwclock -r Mon 04 Jan 2016 03:59:40 PM CET .950405 seconds $ uname -a Linux pluto 4.3.3-gnu #1 SMP Wed Dec 16 18:40:47 UTC 2015 x86_64 GNU/Linux --8<---------------cut here---------------end--------------->8--- > In both Aeva and I's systems, the hardware clock could not be read (and > thus we got 1969) in the most recent system built and installed by > GuixSD, but in the original system install (from Guix 0.9.0), the clock > works just fine. > > Thus my *guess* is that this is a regression in the kernel (either that > or we both "added" some mistake) between 4.2.5 and 4.3.3. Sounds like it. > When I'm not on a train I can try building the "current" system with > Linux-Libre 4.2.5 and see if it's really the kernel. Yes, that would be helpful! It would be nice to check with other X200 users too. Thanks for investigating! Ludo=E2=80=99.