GuixSD resets hardware clock (on Lenovo x200 with libreboot)

  • Done
  • quality assurance status badge
Details
5 participants
  • Christopher Allan Webber
  • Francis Rowe
  • Leo Famulari
  • Ludovic Courtès
  • Mark H Weaver
Owner
unassigned
Submitted by
Christopher Allan Webber
Severity
normal

Debbugs page

Christopher Allan Webber wrote 9 years ago
(address . bug-guix@gnu.org)
87ege42bg6.fsf@dustycloud.org
Hello,

I recently installed GuixSD on the laptop I got fresh from Minifree. I
was happy to see how much worked, but I've noticed a bug that occurs in
GuixSD but not in Debian.

In Debian I can set the hardware clock (with `hwclock -w`) and if I
reboot back into Debian again, I still have the same hardware clock.

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.

This is fairly serious, because this could greatly mess up committing to
git, running makefiles, or simply knowing when I wrote that file to
disk. Also, ssl certs no longer validate, etc.

Any idea what could be causing this? I noticed that if I rebooted it
at the time that it asked me for a passphrase to decrypt /home/ that it
didn't reset the clock, though maybe I should test that again.

My system config file is attached.
;; This is an operating system configuration template ;; for a "desktop" setup with X11. (use-modules (gnu) (gnu system nss)) (use-service-modules desktop) (use-package-modules xfce ratpoison certs) (operating-system (host-name "oolong") (timezone "America/Chicago") (locale "en_US.UTF-8") ;; Assuming /dev/sdX is the target hard disk, and "root" is ;; the label of the target root file system. (bootloader (grub-configuration (device "/dev/sda"))) (mapped-devices (list (mapped-device (source "/dev/sda8") (target "home-luks") (type luks-device-mapping)))) (file-systems `(,(file-system (device "guix") (title 'label) (mount-point "/") (type "ext4")) ,(file-system (device "/dev/mapper/home-luks") (mount-point "/home") (type "ext4")) ,@%base-file-systems)) (users (cons (user-account (name "cwebber") (uid 1000) (comment "Christopher Allan Webber") (group "cwebber") (supplementary-groups '("users" "wheel" "netdev" "audio" "video")) (home-directory "/home/cwebber")) %base-user-accounts)) (groups (cons (user-group (name "cwebber") (id 1000)) %base-groups)) ;; Add Xfce and Ratpoison; that allows us to choose ;; sessions using either of these at the log-in screen. (packages (cons* xfce ratpoison ;desktop environments nss-certs ;for HTTPS access %base-packages)) ;; Use the "desktop" services, which include the X11 ;; log-in service, networking with Wicd, and more. (services %desktop-services) ;; Allow resolution of '.local' host names with mDNS. (name-service-switch %mdns-host-lookup-nss))
Ludovic Courtès wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 22274@debbugs.gnu.org)
87oad5jp4e.fsf@gnu.org
Christopher Allan Webber <cwebber@dustycloud.org> skribis:

Toggle quote (4 lines)
> 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.

HTH,
Ludo’.
Mark H Weaver wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 22274@debbugs.gnu.org)
87lh8amkic.fsf@netris.org
Christopher Allan Webber <cwebber@dustycloud.org> writes:

Toggle quote (11 lines)
> I recently installed GuixSD on the laptop I got fresh from Minifree. I
> was happy to see how much worked, but I've noticed a bug that occurs in
> GuixSD but not in Debian.
>
> In Debian I can set the hardware clock (with `hwclock -w`) and if I
> reboot back into Debian again, I still have the same hardware clock.
>
> 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.

Very strange. FWIW, I've used Libreboot X60 and X200 laptops running
GuixSD quite extensively -- they are my primary development machines --
and I've never seen anything like this.

One possibility that comes to mind is that perhaps your hardware clock
battery is dead, and that sometimes Debian is able to hide that fact by
setting the date via NTP or something. Can you try running "hwclock -r"
after a cold boot into Debian and see what it says?

Toggle quote (4 lines)
> Any idea what could be causing this? I noticed that if I rebooted it
> at the time that it asked me for a passphrase to decrypt /home/ that it
> didn't reset the clock, though maybe I should test that again.

If you're sharing /home between Debian and GuixSD, I wonder if going
back and forth between two different versions of GNOME while sharing the
data in dot-files/directories is causing a problem?

This in turn makes me wonder if the clock is truly being reset during
the GuixSD boot process, or if it might be happening during login to
your desktop environment. Please try the following:

* Cold boot into Debian.
* Set the hardware clock (hwclock -w).
* Read the hardware clock to verify that it works (hwclock -r).
* Reboot into GuixSD.
* Log in to a text console as root and check both the system clock
(date) and the hardware clock (hwclock -r).

Thanks,
Mark
Christopher Allan Webber wrote 9 years ago
(name . Mark H Weaver)(address . mhw@netris.org)(address . 22274@debbugs.gnu.org)
87k2nqypw1.fsf@dustycloud.org
Mark H Weaver writes:

Toggle quote (9 lines)
> Very strange. FWIW, I've used Libreboot X60 and X200 laptops running
> GuixSD quite extensively -- they are my primary development machines --
> and I've never seen anything like this.
>
> One possibility that comes to mind is that perhaps your hardware clock
> battery is dead, and that sometimes Debian is able to hide that fact by
> setting the date via NTP or something. Can you try running "hwclock -r"
> after a cold boot into Debian and see what it says?

Yes it isn't the battery. I've also verified that this happens on my
friend Aeva's minifree x200 w/ Libreboot + Guix. More on that in my
next email.

Toggle quote (22 lines)
>> Any idea what could be causing this? I noticed that if I rebooted it
>> at the time that it asked me for a passphrase to decrypt /home/ that it
>> didn't reset the clock, though maybe I should test that again.
>
> If you're sharing /home between Debian and GuixSD, I wonder if going
> back and forth between two different versions of GNOME while sharing the
> data in dot-files/directories is causing a problem?
>
> This in turn makes me wonder if the clock is truly being reset during
> the GuixSD boot process, or if it might be happening during login to
> your desktop environment. Please try the following:
>
> * Cold boot into Debian.
> * Set the hardware clock (hwclock -w).
> * Read the hardware clock to verify that it works (hwclock -r).
> * Reboot into GuixSD.
> * Log in to a text console as root and check both the system clock
> (date) and the hardware clock (hwclock -r).
>
> Thanks,
> Mark

I've done this and I ran into problems still. However, I think I
figured out the source of them... I suspect there were two problems.
I'll detail in my reply to Ludovic.
Christopher Allan Webber wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87io3aypk7.fsf@dustycloud.org
Ludovic Courtès writes:

Toggle quote (22 lines)
> 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
Ludovic Courtès wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 22274@debbugs.gnu.org)
87r3hxbd7b.fsf@gnu.org
Christopher Allan Webber <cwebber@dustycloud.org> skribis:

Toggle quote (27 lines)
> 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.

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.

Toggle quote (3 lines)
> 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.

Toggle quote (6 lines)
> 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.

Toggle quote (3 lines)
> Not only that, but I verified that my friend Aeva hits the *same*
> "problem" and "solution"...!

Same hardware?

Toggle quote (7 lines)
> *** 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:

Toggle snippet (6 lines)
$ 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

Toggle quote (8 lines)
> 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.

Toggle quote (3 lines)
> 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’.
Christopher Allan Webber wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87fuycyqpm.fsf@dustycloud.org
Ludovic Courtès writes:

Toggle quote (10 lines)
>> 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.

I'll check it. Maybe it never reset the date or the hardware clock at
all, and some attempt of me trying to run 'hwclock -w' on a system set
to 1969 set the date??? I'll look further.

It could be that it had failed to read the hardware clock all along in
recent updates, but never did anything about writing to the hardware
clock.

Toggle quote (7 lines)
>> 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.

Hm ok!

Toggle quote (5 lines)
>> Not only that, but I verified that my friend Aeva hits the *same*
>> "problem" and "solution"...!
>
> Same hardware?

Same hardware, both of us got x200 Libreboot-enabled laptops from
Minifree. She doesn't have Debian on hers though, only GuixSD,
so I was not able to check as many things.

Hilariously, we both found it most visible because we noticed SSL certs
being marked invalid because the machine thought they certs wouldn't be
valid for another 45ish years :)

Toggle quote (20 lines)
>> *** 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---

I'll check /var/log/messages and report back after next reboot into Guix.

Toggle quote (10 lines)
>> 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’.

Okay, I'll try all these things as soon as I'm not tethering from a
phone :)
Francis Rowe wrote 9 years ago
epochfail
(address . 22274@debbugs.gnu.org)
5694A90F.9000408@gluglug.org.uk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pasting from #guix

<francis7> mark_weaver, can you (and also inform others of this) check
<francis7> Quote: "This seems to be an issue in Linux kernel version
4.3 and higher, though it may also affect older releases. We know that
it does not affect Linux kernel version 3.13 (the one used in Trisquel
7, which many libreboot developers and users use). A bisect of the
upstream linux kernel Git repository is in order, so that we can find
out which commit introduced this issue."
<francis7> Can you try said bisect?
<francis7> If not, can you talk to a few others and suggest the same?
<francis7> I ask, since you use Libreboot on a system that is affected
<francis7> We need to know which kernel commit caused this, as a
necessary prerequisite for a fix upstream (kernel.org)
<lfam> francis7: You might also try emailing 22274@debbugs.gnu.org.
That is the bug tracker for our related bug:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWlKkPAAoJEP9Ft0z50c+Uo7MH/RmaXfmI02nXFDset2G1MVv/
oj/j7Yzhp9Mf98mwsV6lcq3JsZLuUiCYY+H9aeXhfHzw2vo+efj5GayHAddCW1Kk
ueOnuLC8AAxwLlC9P4BTa1p0o9v832qMkE9l5/VAU3isj2B0igHzJ6NPG/IVZB+5
AzbXdWfFTGPt9s+LSzfmAZsttYe7Ki5gHF+Q5cktdPSHYDzVur3D4CY4z1vsn/lW
Ozyyd4W87EgeIolTOAFxNXP7rrXCvjkPSXZ5xiFMzP9STtnL1ppnmnvLLit64TCg
S6j74PU1kPIXVL1vBz1zhcZLSfYryJ8zkKpqiRsHqWQVTUHostZEdQ8tP3rPGIQ=
=VYlA
-----END PGP SIGNATURE-----
Leo Famulari wrote 9 years ago
(name . Francis Rowe)(address . info@gluglug.org.uk)(address . 22274@debbugs.gnu.org)
20160112190343.GA25015@jasmine
On Tue, Jan 12, 2016 at 07:19:43AM +0000, Francis Rowe wrote:
Toggle quote (8 lines)
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> pasting from #guix
>
> <francis7> mark_weaver, can you (and also inform others of this) check
> what it says on https://libreboot.org/faq/#epochfail

This relates to the bug whereby the hwclock always thinks it is
1970-01-01.

Toggle quote (29 lines)
> <francis7> Quote: "This seems to be an issue in Linux kernel version
> 4.3 and higher, though it may also affect older releases. We know that
> it does not affect Linux kernel version 3.13 (the one used in Trisquel
> 7, which many libreboot developers and users use). A bisect of the
> upstream linux kernel Git repository is in order, so that we can find
> out which commit introduced this issue."
> <francis7> Can you try said bisect?
> <francis7> If not, can you talk to a few others and suggest the same?
> <francis7> I ask, since you use Libreboot on a system that is affected
> <francis7> We need to know which kernel commit caused this, as a
> necessary prerequisite for a fix upstream (kernel.org)
> <lfam> francis7: You might also try emailing 22274@debbugs.gnu.org.
> That is the bug tracker for our related bug:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22274
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJWlKkPAAoJEP9Ft0z50c+Uo7MH/RmaXfmI02nXFDset2G1MVv/
> oj/j7Yzhp9Mf98mwsV6lcq3JsZLuUiCYY+H9aeXhfHzw2vo+efj5GayHAddCW1Kk
> ueOnuLC8AAxwLlC9P4BTa1p0o9v832qMkE9l5/VAU3isj2B0igHzJ6NPG/IVZB+5
> AzbXdWfFTGPt9s+LSzfmAZsttYe7Ki5gHF+Q5cktdPSHYDzVur3D4CY4z1vsn/lW
> Ozyyd4W87EgeIolTOAFxNXP7rrXCvjkPSXZ5xiFMzP9STtnL1ppnmnvLLit64TCg
> S6j74PU1kPIXVL1vBz1zhcZLSfYryJ8zkKpqiRsHqWQVTUHostZEdQ8tP3rPGIQ=
> =VYlA
> -----END PGP SIGNATURE-----
>
>
>
Christopher Allan Webber wrote 9 years ago
Re: bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87a8o8yoja.fsf@dustycloud.org
Christopher Allan Webber writes:

Toggle quote (13 lines)
>>> 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’.
>
> Okay, I'll try all these things as soon as I'm not tethering from a
> phone :)

Well it took me a bit longer than I said, but I finally tried it :)

My config is attached. Hackily, I copy-pasta'ed the kernel packages
entirely from guix v0.9.0's release. I can confirm that this can read
the hardware clock just fine, whereas the other version of the kernel
can't... so it does indeed look like between Linux-Libre 4.2.5 and
Linux-Libre 4.3.3 we have some sort of regression that leads to this
problem on x200 Minifree Libreboot-enabled laptops, at least.

- Chris
Attachment: config-new-with-old-kernel.scm
Ludovic Courtès wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 22274@debbugs.gnu.org)
87bn8ngp6u.fsf@gnu.org
Christopher Allan Webber <cwebber@dustycloud.org> skribis:

Toggle quote (7 lines)
> My config is attached. Hackily, I copy-pasta'ed the kernel packages
> entirely from guix v0.9.0's release. I can confirm that this can read
> the hardware clock just fine, whereas the other version of the kernel
> can't... so it does indeed look like between Linux-Libre 4.2.5 and
> Linux-Libre 4.3.3 we have some sort of regression that leads to this
> problem on x200 Minifree Libreboot-enabled laptops, at least.

Great, thanks for narrowing it down.

Given that, I think it would be useful to keep a copy of 4.2.5 in Guix
itself. Would you like to provide a patch for that, preferably using
‘(inherit linux-libre)’ rather than copying the whole recipe?

Ludo’.
Christopher Allan Webber wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
871t9g2ljg.fsf@dustycloud.org
Ludovic Courtès writes:

Toggle quote (17 lines)
> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> My config is attached. Hackily, I copy-pasta'ed the kernel packages
>> entirely from guix v0.9.0's release. I can confirm that this can read
>> the hardware clock just fine, whereas the other version of the kernel
>> can't... so it does indeed look like between Linux-Libre 4.2.5 and
>> Linux-Libre 4.3.3 we have some sort of regression that leads to this
>> problem on x200 Minifree Libreboot-enabled laptops, at least.
>
> Great, thanks for narrowing it down.
>
> Given that, I think it would be useful to keep a copy of 4.2.5 in Guix
> itself. Would you like to provide a patch for that, preferably using
> ‘(inherit linux-libre)’ rather than copying the whole recipe?
>
> Ludo’.

Yes, I will work on this.

Also I'm happy to report that I did a fairly thorough testing and
guarantee that this really is the source of the hardware clock reading
error, and it is. I checked both kernel versions about 10 times and
found consistent behavior.

I'm not sure why something in my GuixSD system sometimes sets the
hardware clock and sometimes doesn't yet, though. But that's not as big
of a concern or me.

Anyway, on to do that packaging!
Christopher Allan Webber wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87wpr66cw7.fsf@dustycloud.org
Christopher Allan Webber writes:

Toggle quote (21 lines)
> Ludovic Courtès writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>
>>> My config is attached. Hackily, I copy-pasta'ed the kernel packages
>>> entirely from guix v0.9.0's release. I can confirm that this can read
>>> the hardware clock just fine, whereas the other version of the kernel
>>> can't... so it does indeed look like between Linux-Libre 4.2.5 and
>>> Linux-Libre 4.3.3 we have some sort of regression that leads to this
>>> problem on x200 Minifree Libreboot-enabled laptops, at least.
>>
>> Great, thanks for narrowing it down.
>>
>> Given that, I think it would be useful to keep a copy of 4.2.5 in Guix
>> itself. Would you like to provide a patch for that, preferably using
>> ‘(inherit linux-libre)’ rather than copying the whole recipe?
>>
>> Ludo’.
>
> Yes, I will work on this.

Here's a patch that does just this. Does it look good enough to merge?
From afcd19c4b3cf69ecacf2c34ba3051fc05c830879 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cwebber@dustycloud.org>
Date: Sun, 17 Jan 2016 20:34:25 -0800
Subject: [PATCH] gnu: Add linux-libre-4.2.5

This older version of linux-libre is being added because it was found
that newer versions (or at least 4.3.3) of linux-libre were not reading
the hardware clock on (at least Libreboot-enabled) Thinkpad x200
machines.

* gnu/linux.scm (linux-libre-4.2.5): New variable.
---
gnu/packages/linux.scm | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

Toggle diff (29 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 779b9c8..de4d1bd 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -317,6 +317,22 @@ It has been modified to remove all non-free binary blobs.")
(license license:gpl2)
(home-page "http://www.gnu.org/software/linux-libre/"))))
+;; This older version of linux-libre is being added because it was found
+;; that newer versions (or at least 4.3.3) of linux-libre were not reading
+;; the hardware clock on (at least Libreboot-enabled) Thinkpad x200
+;; machines.
+
+(define-public linux-libre-4.2.5
+ (package
+ (inherit linux-libre)
+ (version "4.2.5")
+ (source (origin
+ (method url-fetch)
+ (uri (linux-libre-urls version))
+ (sha256
+ (base32
+ "13ar9sghm2g5w2km9x2d07q3lh81rz286d6slklv56qanm24chzx"))))))
+
;;;
;;; Pluggable authentication modules (PAM).
--
2.1.4
Christopher Allan Webber wrote 9 years ago
Re: bug#22274: epochfail
(name . Francis Rowe)(address . info@gluglug.org.uk)(address . 22274@debbugs.gnu.org)
87vb6q6cok.fsf@dustycloud.org
Toggle quote (11 lines)
> pasting from #guix
>
> <francis7> mark_weaver, can you (and also inform others of this) check
> what it says on https://libreboot.org/faq/#epochfail
> <francis7> Quote: "This seems to be an issue in Linux kernel version
> 4.3 and higher, though it may also affect older releases. We know that
> it does not affect Linux kernel version 3.13 (the one used in Trisquel
> 7, which many libreboot developers and users use). A bisect of the
> upstream linux kernel Git repository is in order, so that we can find
> out which commit introduced this issue."

confirms that this happens sometime between Linux-Libre 4.2.5 and 4.3.3
so that narrows things down a bit.
Christopher Allan Webber wrote 9 years ago
Re: bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87si1u65dy.fsf@dustycloud.org
Christopher Allan Webber writes:

Toggle quote (2 lines)
> Here's a patch that does just this. Does it look good enough to merge?

Forgot the (C) line.
From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cwebber@dustycloud.org>
Date: Sun, 17 Jan 2016 20:34:25 -0800
Subject: [PATCH] gnu: Add linux-libre-4.2.5

This older version of linux-libre is being added because it was found
that newer versions (or at least 4.3.3) of linux-libre were not reading
the hardware clock on (at least Libreboot-enabled) Thinkpad x200
machines.

* gnu/linux.scm (linux-libre-4.2.5): New variable.
---
gnu/packages/linux.scm | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

Toggle diff (37 lines)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 779b9c8..217d7fe 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -6,6 +6,7 @@
;;; Copyright © 2015 Federico Beffa <beffa@fbengineering.ch>
;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer <taylanbayirli@gmail.com>
;;; Copyright © 2015 Efraim Flashner <efraim@flashner.co.il>
+;;; Copyright © 2016 Christopher Allan Webber <cwebber@dustycloud.org>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -317,6 +318,22 @@ It has been modified to remove all non-free binary blobs.")
(license license:gpl2)
(home-page "http://www.gnu.org/software/linux-libre/"))))
+;; This older version of linux-libre is being added because it was found
+;; that newer versions (or at least 4.3.3) of linux-libre were not reading
+;; the hardware clock on (at least Libreboot-enabled) Thinkpad x200
+;; machines.
+
+(define-public linux-libre-4.2.5
+ (package
+ (inherit linux-libre)
+ (version "4.2.5")
+ (source (origin
+ (method url-fetch)
+ (uri (linux-libre-urls version))
+ (sha256
+ (base32
+ "13ar9sghm2g5w2km9x2d07q3lh81rz286d6slklv56qanm24chzx"))))))
+
;;;
;;; Pluggable authentication modules (PAM).
--
2.6.3
Ludovic Courtès wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 22274@debbugs.gnu.org)
87k2n67bmd.fsf@gnu.org
Christopher Allan Webber <cwebber@dustycloud.org> skribis:

Toggle quote (10 lines)
> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
> From: Christopher Allan Webber <cwebber@dustycloud.org>
> Date: Sun, 17 Jan 2016 20:34:25 -0800
> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>
> This older version of linux-libre is being added because it was found
> that newer versions (or at least 4.3.3) of linux-libre were not reading
> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
> machines.

Since this text is available as a comment, I think it’s not necessary to
keep it here.

Toggle quote (1 lines)
> * gnu/linux.scm (linux-libre-4.2.5): New variable.
^^^^
Typo. :-)

Toggle quote (5 lines)
> +;; This older version of linux-libre is being added because it was found
> +;; that newer versions (or at least 4.3.3) of linux-libre were not reading
> +;; the hardware clock on (at least Libreboot-enabled) Thinkpad x200
> +;; machines.

Maybe add “See http://bugs.gnu.org/22274.”

Other than that, if it builds, it’s all good! :-)

Thank you,
Ludo’.
Christopher Allan Webber wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87r3he5vpl.fsf@dustycloud.org
Ludovic Courtès writes:

Toggle quote (15 lines)
> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>
>> This older version of linux-libre is being added because it was found
>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>> machines.
>
> Since this text is available as a comment, I think it’s not necessary to
> keep it here.

Okay, removed.

Toggle quote (4 lines)
>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
> ^^^^
> Typo. :-)

Ha! Unintentional joke... :)

Toggle quote (12 lines)
>> +;; This older version of linux-libre is being added because it was found
>> +;; that newer versions (or at least 4.3.3) of linux-libre were not reading
>> +;; the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>> +;; machines.
>
> Maybe add “See <http://bugs.gnu.org/22274>.”
>
> Other than that, if it builds, it’s all good! :-)
>
> Thank you,
> Ludo’.

Great, I made those changes and pushed it! I'm using it already! :)
Mark H Weaver wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)
87powxttq8.fsf@netris.org
Christopher Allan Webber <cwebber@dustycloud.org> writes:

Toggle quote (12 lines)
> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
> From: Christopher Allan Webber <cwebber@dustycloud.org>
> Date: Sun, 17 Jan 2016 20:34:25 -0800
> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>
> This older version of linux-libre is being added because it was found
> that newer versions (or at least 4.3.3) of linux-libre were not reading
> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
> machines.
>
> * gnu/linux.scm (linux-libre-4.2.5): New variable.

I would say that the variable should be named 'linux-libre-4.2', which
would always be bound to the latest 4.2.x. However, there's another
problem: the 4.2 branch is no longer supported upstream, so it will no
longer receive security updates and other important fixes.

I suggest that we instead add linux-libre-4.1, which is still supported
upstream and is designated as an LTS branch. Would that be okay?

Another issue is that the kernel config for 4.3 is being used here. I
guess maybe that's working well enough in this case, but really our
kernel packages should be refactored somewhat to make this nicer.

One more thing: Francis Rowe told me that the coreboot developers have
determined that this is a bug on their side, and libreboot will
cherry-pick the fix soon, if it hasn't already.

Thanks!
Mark
Ludovic Courtès wrote 9 years ago
(name . Mark H Weaver)(address . mhw@netris.org)
87r3hd8pm2.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (22 lines)
> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>
>> This older version of linux-libre is being added because it was found
>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>> machines.
>>
>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>
> I would say that the variable should be named 'linux-libre-4.2', which
> would always be bound to the latest 4.2.x. However, there's another
> problem: the 4.2 branch is no longer supported upstream, so it will no
> longer receive security updates and other important fixes.
>
> I suggest that we instead add linux-libre-4.1, which is still supported
> upstream and is designated as an LTS branch. Would that be okay?

If it works for Christopher, that’s a good idea.

Toggle quote (4 lines)
> Another issue is that the kernel config for 4.3 is being used here. I
> guess maybe that's working well enough in this case, but really our
> kernel packages should be refactored somewhat to make this nicer.

Yeah, though that’s probably beyond the scope of this particular issue.

Toggle quote (4 lines)
> One more thing: Francis Rowe told me that the coreboot developers have
> determined that this is a bug on their side, and libreboot will
> cherry-pick the fix soon, if it hasn't already.

Interesting. Any links to the bug report or commit?

Thanks for your feedback!

Ludo’.
Mark H Weaver wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22274@debbugs.gnu.org)
87lh7ltrxk.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (32 lines)
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>>
>>> This older version of linux-libre is being added because it was found
>>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>>> machines.
>>>
>>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>>
>> I would say that the variable should be named 'linux-libre-4.2', which
>> would always be bound to the latest 4.2.x. However, there's another
>> problem: the 4.2 branch is no longer supported upstream, so it will no
>> longer receive security updates and other important fixes.
>>
>> I suggest that we instead add linux-libre-4.1, which is still supported
>> upstream and is designated as an LTS branch. Would that be okay?
>
> If it works for Christopher, that’s a good idea.
>
>> Another issue is that the kernel config for 4.3 is being used here. I
>> guess maybe that's working well enough in this case, but really our
>> kernel packages should be refactored somewhat to make this nicer.
>
> Yeah, though that’s probably beyond the scope of this particular issue.

Agreed.

Toggle quote (4 lines)
>> One more thing: Francis Rowe told me that the coreboot developers have
>> determined that this is a bug on their side, and libreboot will
>> cherry-pick the fix soon, if it hasn't already.

"determined" may have been too strong a word. Maybe better to say that
they "think" it's a coreboot bug, exposed by a change in the kernel.

Toggle quote (2 lines)
> Interesting. Any links to the bug report or commit?


Mark
Christopher Allan Webber wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bn8hi6d2.fsf@dustycloud.org
Ludovic Courtès writes:

Toggle quote (26 lines)
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>>
>>> This older version of linux-libre is being added because it was found
>>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>>> machines.
>>>
>>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>>
>> I would say that the variable should be named 'linux-libre-4.2', which
>> would always be bound to the latest 4.2.x. However, there's another
>> problem: the 4.2 branch is no longer supported upstream, so it will no
>> longer receive security updates and other important fixes.
>>
>> I suggest that we instead add linux-libre-4.1, which is still supported
>> upstream and is designated as an LTS branch. Would that be okay?
>
> If it works for Christopher, that’s a good idea.

Fine by me, assuming it works. I can test it works fine probably tomorrow.

Toggle quote (6 lines)
>> Another issue is that the kernel config for 4.3 is being used here. I
>> guess maybe that's working well enough in this case, but really our
>> kernel packages should be refactored somewhat to make this nicer.
>
> Yeah, though that’s probably beyond the scope of this particular issue.

I haven't noticed any problems, though

Toggle quote (6 lines)
>> One more thing: Francis Rowe told me that the coreboot developers have
>> determined that this is a bug on their side, and libreboot will
>> cherry-pick the fix soon, if it hasn't already.
>
> Interesting. Any links to the bug report or commit?

Yeah, Francis told me this as well.

I guess this means that I should reflash libreboot once this change
happens. I'm a little bit nervous to do that! :)
Mark H Weaver wrote 9 years ago
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)
87io2734sa.fsf@netris.org
Hi,

Christopher Allan Webber <cwebber@dustycloud.org> writes:

Toggle quote (30 lines)
> Ludovic Courtès writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>>
>>>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>>>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>>>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>>>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>>>
>>>> This older version of linux-libre is being added because it was found
>>>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>>>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>>>> machines.
>>>>
>>>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>>>
>>> I would say that the variable should be named 'linux-libre-4.2', which
>>> would always be bound to the latest 4.2.x. However, there's another
>>> problem: the 4.2 branch is no longer supported upstream, so it will no
>>> longer receive security updates and other important fixes.
>>>
>>> I suggest that we instead add linux-libre-4.1, which is still supported
>>> upstream and is designated as an LTS branch. Would that be okay?
>>
>> If it works for Christopher, that’s a good idea.
>
> Fine by me, assuming it works. I can test it works fine probably tomorrow.

I just added a 'linux-libre-4.1' variable. Can you test to make sure it
works for you? I'd like to remove linux-libre-4.2.5 ASAP because 4.2.x
is no longer supported upstream and contains security flaws.

Thanks!
Mark
Ludovic Courtès wrote 9 years ago
(name . Mark H Weaver)(address . mhw@netris.org)
87twlnl2y0.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (36 lines)
> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Ludovic Courtès writes:
>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>>>
>>>>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>>>>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>>>>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>>>>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>>>>
>>>>> This older version of linux-libre is being added because it was found
>>>>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>>>>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>>>>> machines.
>>>>>
>>>>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>>>>
>>>> I would say that the variable should be named 'linux-libre-4.2', which
>>>> would always be bound to the latest 4.2.x. However, there's another
>>>> problem: the 4.2 branch is no longer supported upstream, so it will no
>>>> longer receive security updates and other important fixes.
>>>>
>>>> I suggest that we instead add linux-libre-4.1, which is still supported
>>>> upstream and is designated as an LTS branch. Would that be okay?
>>>
>>> If it works for Christopher, that’s a good idea.
>>
>> Fine by me, assuming it works. I can test it works fine probably tomorrow.
>
> I just added a 'linux-libre-4.1' variable. Can you test to make sure it
> works for you? I'd like to remove linux-libre-4.2.5 ASAP because 4.2.x
> is no longer supported upstream and contains security flaws.

Regardless, it seems that this bug can be closed on the Guix side; WDYT?

Ludo’.
Mark H Weaver wrote 9 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)
874mdnxju2.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (38 lines)
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>
>>>>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>>>>
>>>>>> From e60db83ffff23c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>>>>>> From: Christopher Allan Webber <cwebber@dustycloud.org>
>>>>>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>>>>>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>>>>>
>>>>>> This older version of linux-libre is being added because it was found
>>>>>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>>>>>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>>>>>> machines.
>>>>>>
>>>>>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>>>>>
>>>>> I would say that the variable should be named 'linux-libre-4.2', which
>>>>> would always be bound to the latest 4.2.x. However, there's another
>>>>> problem: the 4.2 branch is no longer supported upstream, so it will no
>>>>> longer receive security updates and other important fixes.
>>>>>
>>>>> I suggest that we instead add linux-libre-4.1, which is still supported
>>>>> upstream and is designated as an LTS branch. Would that be okay?
>>>>
>>>> If it works for Christopher, that’s a good idea.
>>>
>>> Fine by me, assuming it works. I can test it works fine probably tomorrow.
>>
>> I just added a 'linux-libre-4.1' variable. Can you test to make sure it
>> works for you? I'd like to remove linux-libre-4.2.5 ASAP because 4.2.x
>> is no longer supported upstream and contains security flaws.

Chris reported on IRC that linux-libre-4.1 works for him, so I removed
linux-libre-4.2.5.

Toggle quote (2 lines)
> Regardless, it seems that this bug can be closed on the Guix side; WDYT?

Agreed. I've closed the bug.

Thanks,
Mark
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 22274@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 22274
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help