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

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

[Christopher Allan Webber]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

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.


[-- Attachment #2: config-new.scm --]
[-- Type: text/plain, Size: 1958 bytes --]

;; 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))

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

[Mark H Weaver]

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

> 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?

> 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

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

[Christopher Allan Webber]

Mark H Weaver writes:

> 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.

>> 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.

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

[Ludovic Courtès]

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.

HTH,
Ludo’.

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

[Christopher Allan Webber]

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

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

[Ludovic Courtès]

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

> 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.

> 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’.

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

[Christopher Allan Webber]

Ludovic Courtès writes:

>> 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.

>> 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!

>> 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 :)

>> *** 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.

>> 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 :)

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

[Christopher Allan Webber]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Christopher Allan Webber writes:

>>> 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 #2: config-new-with-old-kernel.scm --]
[-- Type: application/octet-stream, Size: 11585 bytes --]

;; This is an operating system configuration template
;; for a "desktop" setup with X11.

(use-modules (gnu) (gnu system nss)
             ;; dump in the stuff from (gnu packages linux)
             ((guix licenses)
              #:hide (zlib))
             (gnu packages)
             (gnu packages compression)
             (gnu packages gcc)
             (gnu packages flex)
             (gnu packages bison)
             (gnu packages admin)
             (gnu packages gperf)
             (gnu packages libusb)
             (gnu packages ncurses)
             (gnu packages pciutils)
             (gnu packages databases)
             (gnu packages perl)
             (gnu packages pkg-config)
             (gnu packages python)
             (gnu packages slang)
             (gnu packages algebra)
             (gnu packages gettext)
             (gnu packages glib)
             (gnu packages pulseaudio)
             (gnu packages attr)
             (gnu packages xml)
             (gnu packages autotools)
             (gnu packages texinfo)
             (gnu packages check)
             (gnu packages maths)
             (gnu packages base)
             (gnu packages rrdtool)
             (gnu packages elf)
             (gnu packages gtk)
             (gnu packages docbook)
             (gnu packages asciidoc)
             (gnu packages readline)
             (gnu packages calendar)
             (guix packages)
             (guix download)
             (guix utils)
             (guix build-system gnu)
             (guix build-system cmake)
             (guix build-system python)
             (guix build-system trivial)
             (srfi srfi-26)
             (ice-9 match))
(use-service-modules desktop)
(use-package-modules xfce ratpoison certs)

(define-public (system->linux-architecture arch)
  "Return the Linux architecture name for ARCH, a Guix system name such as
\"x86_64-linux\"."
  (let ((arch (car (string-split arch #\-))))
    (cond ((string=? arch "i686") "i386")
          ((string-prefix? "mips" arch) "mips")
          ((string-prefix? "arm" arch) "arm")
          (else arch))))

(define (linux-libre-urls version)
  "Return a list of URLs for Linux-Libre VERSION."
  (list (string-append
         "http://linux-libre.fsfla.org/pub/linux-libre/releases/"
         version "-gnu/linux-libre-" version "-gnu.tar.xz")

        ;; XXX: Work around <http://bugs.gnu.org/14851>.
        (string-append
         "ftp://alpha.gnu.org/gnu/guix/mirror/linux-libre-"
         version "-gnu.tar.xz")

        ;; Maybe this URL will become valid eventually.
        (string-append
         "mirror://gnu/linux-libre/" version "-gnu/linux-libre-"
         version "-gnu.tar.xz")))


(define-public module-init-tools
  (package
    (name "module-init-tools")
    (version "3.16")
    (source (origin
             (method url-fetch)
             (uri (string-append
                   "mirror://kernel.org/linux/utils/kernel/module-init-tools/module-init-tools-"
                   version ".tar.bz2"))
             (sha256
              (base32
               "0jxnz9ahfic79rp93l5wxcbgh4pkv85mwnjlbv1gz3jawv5cvwp1"))
             (patches
              (list (search-patch "module-init-tools-moduledir.patch")))))
    (build-system gnu-build-system)
    (arguments
     ;; FIXME: The upstream tarball lacks man pages, and building them would
     ;; require DocBook & co.  We used to use Gentoo's pre-built man pages,
     ;; but they vanished.  In the meantime, fake it.
     '(#:phases (alist-cons-before
                 'configure 'fake-docbook
                 (lambda _
                   (substitute* "Makefile.in"
                     (("^DOCBOOKTOMAN.*$")
                      "DOCBOOKTOMAN = true\n")))
                 %standard-phases)))
    (home-page "http://www.kernel.org/pub/linux/utils/kernel/module-init-tools/")
    (synopsis "Tools for loading and managing Linux kernel modules")
    (description
     "Tools for loading and managing Linux kernel modules, such as `modprobe',
`insmod', `lsmod', and more.")
    (license gpl2+)))

(define %boot-logo-patch
  ;; Linux-Libre boot logo featuring Freedo and a gnu.
  (origin
    (method url-fetch)
    (uri (string-append "http://www.fsfla.org/svn/fsfla/software/linux-libre/"
                        "lemote/gnewsense/branches/3.16/100gnu+freedo.patch"))
    (sha256
     (base32
      "1hk9swxxc80bmn2zd2qr5ccrjrk28xkypwhl4z0qx4hbivj7qm06"))))

(define (kernel-config system)
  "Return the absolute file name of the Linux-Libre build configuration file
for SYSTEM, or #f if there is no configuration for SYSTEM."
  (define (lookup file)
    (let ((file (string-append "gnu/packages/" file)))
      (search-path %load-path file)))

  (match system
    ("i686-linux"
     (lookup "linux-libre-i686.conf"))
    ("x86_64-linux"
     (lookup "linux-libre-x86_64.conf"))
    (_
     #f)))



(define-public linux-libre
  (let* ((version "4.2.5")
         (build-phase
          '(lambda* (#:key system inputs #:allow-other-keys #:rest args)
             ;; Apply the neat patch.
             (system* "patch" "-p1" "--force"
                      "-i" (assoc-ref inputs "patch/freedo+gnu"))

             (let ((arch (car (string-split system #\-))))
               (setenv "ARCH"
                       (cond ((string=? arch "i686") "i386")
                             ((string=? arch "mips64el") "mips")
                             (else arch)))
               (format #t "`ARCH' set to `~a'~%" (getenv "ARCH")))

             (let ((build  (assoc-ref %standard-phases 'build))
                   (config (assoc-ref inputs "kconfig")))

               ;; Use the architecture-specific config if available, and
               ;; 'defconfig' otherwise.
               (if config
                   (begin
                     (copy-file config ".config")
                     (chmod ".config" #o666))
                   (system* "make" "defconfig"))

               ;; Appending works even when the option wasn't in the
               ;; file.  The last one prevails if duplicated.
               (let ((port (open-file ".config" "a")))
                 (display (string-append "CONFIG_NET_9P=m\n"
                                         "CONFIG_NET_9P_VIRTIO=m\n"
                                         "CONFIG_VIRTIO_BLK=m\n"
                                         "CONFIG_VIRTIO_NET=m\n"
                                         ;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
                                         "CONFIG_DEVPTS_MULTIPLE_INSTANCES=y\n"
                                         "CONFIG_VIRTIO_PCI=m\n"
                                         "CONFIG_VIRTIO_BALLOON=m\n"
                                         "CONFIG_VIRTIO_MMIO=m\n"
                                         "CONFIG_FUSE_FS=m\n"
                                         "CONFIG_CIFS=m\n"
                                         "CONFIG_9P_FS=m\n")
                          port)
                 (close-port port))

               (zero? (system* "make" "oldconfig"))

               ;; Call the default `build' phase so `-j' is correctly
               ;; passed.
               (apply build #:make-flags "all" args))))
         (install-phase
          `(lambda* (#:key inputs outputs #:allow-other-keys)
             (let* ((out    (assoc-ref outputs "out"))
                    (moddir (string-append out "/lib/modules"))
                    (mit    (assoc-ref inputs "module-init-tools")))
               (mkdir-p moddir)
               (for-each (lambda (file)
                           (copy-file file
                                      (string-append out "/" (basename file))))
                         (find-files "." "^(bzImage|vmlinuz|System\\.map)$"))
               (copy-file ".config" (string-append out "/config"))
               (zero? (system* "make"
                               (string-append "DEPMOD=" mit "/sbin/depmod")
                               (string-append "MODULE_DIR=" moddir)
                               (string-append "INSTALL_PATH=" out)
                               (string-append "INSTALL_MOD_PATH=" out)
                               "INSTALL_MOD_STRIP=1"
                               "modules_install"))))))
   (package
    (name "linux-libre")
    (version version)
    (source (origin
             (method url-fetch)
             (uri (linux-libre-urls version))
             (sha256
              (base32
               "13ar9sghm2g5w2km9x2d07q3lh81rz286d6slklv56qanm24chzx"))))
    (build-system gnu-build-system)
    (supported-systems '("x86_64-linux" "i686-linux"))
    (native-inputs `(("perl" ,perl)
                     ("bc" ,bc)
                     ("module-init-tools" ,module-init-tools)
                     ("patch/freedo+gnu" ,%boot-logo-patch)

                     ,@(let ((conf (kernel-config (or (%current-target-system)
                                                      (%current-system)))))
                         (if conf
                             `(("kconfig" ,conf))
                             '()))))
    (arguments
     `(#:modules ((guix build gnu-build-system)
                  (guix build utils)
                  (srfi srfi-1)
                  (ice-9 match))
       #:phases (alist-replace
                 'build ,build-phase
                 (alist-replace
                  'install ,install-phase
                  (alist-delete 'configure %standard-phases)))
       #:tests? #f))
    (synopsis "100% free redistribution of a cleaned Linux kernel")
    (description
     "GNU Linux-Libre is a free (as in freedom) variant of the Linux kernel.
It has been modified to remove all non-free binary blobs.")
    (license gpl2)
    (home-page "http://www.gnu.org/software/linux-libre/"))))


(operating-system
  (host-name "oolong")
  (timezone "America/Chicago")
  (locale "en_US.UTF-8")

  (kernel linux-libre)

  ;; 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))

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

[Ludovic Courtès]

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’.

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

[Christopher Allan Webber]

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.

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!

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

[Christopher Allan Webber]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Christopher Allan Webber writes:

> 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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-Add-linux-libre-4.2.5.patch --]
[-- Type: text/x-diff, Size: 1507 bytes --]

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(+)

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"))))))
+
 \f
 ;;;
 ;;; Pluggable authentication modules (PAM).
-- 
2.1.4

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

[Christopher Allan Webber]

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

Christopher Allan Webber writes:

> Here's a patch that does just this.  Does it look good enough to merge?

Forgot the (C) line.


[-- Attachment #2: 0001-gnu-Add-linux-libre-4.2.5.patch --]
[-- Type: text/x-diff, Size: 1849 bytes --]

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(+)

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"))))))
+
 \f
 ;;;
 ;;; Pluggable authentication modules (PAM).
-- 
2.6.3

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

[Ludovic Courtès]

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.

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

> +;; 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’.

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

[Christopher Allan Webber]

Ludovic Courtès writes:

> 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.

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

Ha!  Unintentional joke... :)

>> +;; 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! :)

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

[Mark H Weaver]

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?

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

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

[Ludovic Courtès]

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.

> 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’.

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

[Mark H Weaver]

ludo@gnu.org (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.
>
>> 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.

>> 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.

> Interesting.  Any links to the bug report or commit?

https://review.coreboot.org/#/c/11853/

     Mark

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

[Christopher Allan Webber]

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.

>> 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 

>> 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! :)

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

[Mark H Weaver]

Hi,

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.

    Thanks!
      Mark

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

[Ludovic Courtès]

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.

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

Ludo’.

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

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> 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.

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

Agreed.  I've closed the bug.

     Thanks,
       Mark

bug#22274: epochfail

[Francis Rowe]

-----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
<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-----

bug#22274: epochfail

[Leo Famulari]

On Tue, Jan 12, 2016 at 07:19:43AM +0000, Francis Rowe wrote:
> -----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. 

> <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-----
> 
> 
> 

bug#22274: epochfail

[Christopher Allan Webber]

> 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."

See also http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22274#38 which
confirms that this happens sometime between Linux-Libre 4.2.5 and 4.3.3
so that narrows things down a bit.