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