bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

[Christopher Allan Webber <cwebber@dustycloud.org>]

Ludovic Courtès writes:

> Christopher Allan Webber <cwebber@dustycloud.org> 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