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

[Ludovic Courtès]

Christopher Allan Webber <address@hidden> skribis:

> Ludovic Courtès writes:
>
>> Christopher Allan Webber <address@hidden> 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.

Could you check in /var/log/messages or nearby if there were relevant
messages from ntpd?

I wouldn’t expect it to reset the date.  I always run it on my laptop,
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’m open to discussion.  My impression is that it’s “usually”
enabled by default on desktop distros.  Then again I’ve been told that
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’.