From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot) Date: Sun, 03 Jan 2016 21:39:35 -0600 Message-ID: <87io3aypk7.fsf@dustycloud.org> References: <87ege42bg6.fsf@dustycloud.org> <87oad5jp4e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG5vX-0002ae-Gp for bug-guix@gnu.org; Mon, 04 Jan 2016 09:16:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG5vW-0002sf-HO for bug-guix@gnu.org; Mon, 04 Jan 2016 09:16:03 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:49014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG5vW-0002sb-EV for bug-guix@gnu.org; Mon, 04 Jan 2016 09:16:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aG5vW-0003R7-Au for bug-guix@gnu.org; Mon, 04 Jan 2016 09:16:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87oad5jp4e.fsf@gnu.org> 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 22274@debbugs.gnu.org Ludovic Courtès 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’s > 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 ‘ntp-service-type’ from (gnu services > networking) first… > > 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. 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. 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. Not only that, but I verified that my friend Aeva hits the *same* "problem" and "solution"...! *** 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 (NOTE: aeva did not hit the hwclock -r ... but she also did not do "hwclock -w" from Debian (she did it from GuixSD instead)) *** Initial Guix system (Linux-Libre 4.2.5) *** bash-4.3$ date Sat Jan 2 20:39:30 CST 2016 bash-4.3$ sudo hwclock -r Sun 03 Jan 2016 02:39:48 AM America .821300 seconds 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. 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. Looks like we're on the right track to sorting this out....! - Chris