bug#34333: Docker daemon failing to start on boot

Hi, I am having an issue with the docker daemon as a service in guixsd. It seems that dockerd will not start on boot, but it will successfully start after running "guix system reconfigure". Here is my config.scm: (use-modules (gnu) (gnu system nss) (gnu services)

bug#34333: Docker daemon failing to start on boot

host networking is set up. I've added it--let's see. Allan, can you guix pull and guix reconfigure and then try again? I guix pulled and guix system reconfigured. After a successful reconfigure and reboot, the service was still not started. -- Allan Adair +47 468 12 135 al..

bug#34333: Docker daemon failing to start on boot

On 2019-02-11 17:31, Danny Milosavljevic wrote: Hi Allan, I've added some more requirements--let's see. Can you guix pull and guix reconfigure and then try again once more? Still no luck. Do you face the same issue? -- Allan Adair +47 468 12 135 al...@adair.io http://allan.adair.io

bug#34333: Docker daemon failing to start on boot

e I have included dockerd in my user profile. I can also "guix system reconfigure" at this point to start the dockerd service, but then at the next boot it will still not start. Danny Milosavljevic writes: > Hi Allan, > > On Tue, 12 Feb 2019 09:05:10 + > A

bug#34333: Docker daemon failing to start on boot

it will still not >> > start. >> >> I can confirm this behaviour, though I haven't yet investigated it >> further. > > Could this be yet another manifestation of >https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34580 ? > Services not started on boot? > > Andreas I'm not so sure. One thing that I am unable to do is "herd start dockerd". -- Allan Adair http://allan.adair.io

bug#34333: Docker daemon failing to start on boot

Björn Höfling writes: > On Fri, 1 Mar 2019 14:09:32 +0100 > Andreas Enge wrote: > >> On Fri, Mar 01, 2019 at 09:58:20AM +0100, Allan Adair wrote: >> > >> > I am however able to execute "sudo herd start >> > >> > dockerd" after bootin

bug#34333: Docker daemon failing to start on boot

Hi Danny. Sorry for the late response. I was offline for the last week or so. I ended up having to repeat the first command with sudo privileges. Please see below. Danny Milosavljevic writes: > Hi, > > On Fri, 01 Mar 2019 14:50:39 +0100 > Allan Adair wrote: > >&g

bug#34333: Docker daemon failing to start on boot

Hi Danny. Danny Milosavljevic writes: > Hi Allan, > > On Mon, 11 Mar 2019 09:59:19 +0100 > Allan Adair wrote: > >> Sorry for the late response. I was offline for the last week or so. > > No problem! > >> >> I ended up having to repeat the first c

bug#34333: Docker daemon failing to start on boot

67+01:00" level=info msg="Loading containers: start." time="2019-03-18T14:43:01.596297744+01:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address" time="2019

bug#34333: Docker daemon failing to start on boot

Danny Milosavljevic writes: > Hi Allan, > > I've pushed a new way to get rid of this bug to guix master. > > Could you try > > guix pull > > and then > > guix reconfigure > > and report back? Success! Thank you very much. -- Allan Adair http://allan.adair.io

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

t;)) ,@%base-file-systems)) (users (cons (user-account (name "cwebber") (uid 1000) (comment "Christopher Allan Webber") (group "cwebber") (supplementary-groups '("users&

bug#19219: New command-line syntax for package + version?

Ludovic Courtès writes: >>> guile@1.8 >>> guile@1.8:doc >>> >>> I’m not sure if we should also allow: >>> >>> guile:doc@1.8 >>> >>> Thoughts? >> >> I'm OK with that. Since choosing the reserved characters is not a >> technical decision, maybe we could poll users? > > Yes, why not (bikeshedd

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

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

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

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

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

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

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

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

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

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

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

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

bug#22274: epochfail

> pasting from #guix > > mark_weaver, can you (and also inform others of this) check > what it says on https://libreboot.org/faq/#epochfail > 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 Lin

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

Christopher Allan Webber writes: > Here's a patch that does just this. Does it look good enough to merge? Forgot the (C) line. >From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 From: Christopher Allan Webber Date: Sun, 17 Jan 2016 20:34:25 -0800 Subject: [PATC

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

Ludovic Courtès writes: > Christopher Allan Webber skribis: > >> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >> From: Christopher Allan Webber >> Date: Sun, 17 Jan 2016 20:34:25 -0800 >> Subject: [PATCH] gnu: Add linux-libre-4.2.5 >

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

Ludovic Courtès writes: > Mark H Weaver skribis: > >> Christopher Allan Webber writes: >> >>> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >>> From: Christopher Allan Webber >>> Date: Sun, 17 Jan 2016 20:34:25 -0800 &g

bug#22588: root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Ludovic Courtès writes: > OTOH, hacking it is very tempting, like: > > --8<---cut here---start->8--- > scheme@(guile-user)> ,use (guix build bournish) > scheme@(guile-user)> ,bournish > Happy hacking with Bournish! To switch back, type `,L scheme'. > bournish@(

bug#22626: Postgres service fails on adding user

Heya all... guix system config attached. I tried doing a guix system reconfigure and it failboat'ed. Here's what happened: adding user 'postgres'... useradd: group 'postgres' does not exist Backtrace: In ice-9/boot-9.scm: 63: 19 [call-with-prompt prompt0 ...] In ice-9/eval.scm:

bug#22633: Provide a kvm-less qemu / guix system vm

So on my Libreboot-enabled machine, KVM does not work. In fact, even starting qemu with KVM enabled on it appears to crash my whole system. Not only does "guix system vm" not work, even "guix system vm-image" can take the whole machine down! It would be nice to have a --no-kvm switch, because I'd

bug#22626: Postgres service fails on adding user

Ludovic Courtès writes: > Christopher Allan Webber skribis: > >> Heya all... guix system config attached. I tried doing a guix system >> reconfigure and it failboat'ed. Here's what happened: >> >> adding user 'postgres'... >> useradd:

bug#22626: Postgres service fails on adding user

Ludovic Courtès writes: > Apparently there’s a stale lock file that prevents ‘groupadd’ from > succeeding, maybe from an earlier crash or something? > > Could you forcefully remove /etc/*.lock and retry? Well, that fixed it! I guess I could have guessed by the context clues being dumped into std

bug#22633: Provide a kvm-less qemu / guix system vm

Ludovic Courtès writes: > Jookia <166...@gmail.com> skribis: > >> We should probably also blacklist kvm on Libreboot machines too somehow, > > A simple way to achieve this is with: > > (operating-system > ;; … > (kernel-arguments '("modprobe.blacklist=kvm-intel,kvm"))) I tried this:

bug#22633: Provide a kvm-less qemu / guix system vm

Leo Famulari writes: > On Fri, Feb 12, 2016 at 09:50:09AM +1100, Jookia wrote: >> On Thu, Feb 11, 2016 at 09:26:12AM -0800, Christopher Allan Webber wrote: >> > So on my Libreboot-enabled machine, KVM does not work. In fact, even >> > starting qemu with KVM enable

bug#22139: Indirect dependencies are not grafted

Mark Weaver laid out a plan that he thinks would work on IRC a couple of years ago, and referenced it yesterday on #guix. Here it is: https://gnunet.org/bot/log/guix/2014-09-25#T480219 Some further conversation: https://gnunet.org/bot/log/guix/2014-10-27#T502706

bug#22633: Provide a kvm-less qemu / guix system vm

Ludovic Courtès writes: > Libkmod honors ‘modprobe.blacklist’ (in ‘kcmdline_parse_result’ in > libkmod-config.c) and eudev passes KMOD_PROBE_APPLY_BLACKLIST > unconditionally in udev-builtin-kmod.c (meaning it honors it too.) > > However, there’s a hyphen-vs-underscore issue, I think. Namely, the

bug#22633: Provide a kvm-less qemu / guix system vm

Christopher Allan Webber writes: > Ludovic Courtès writes: > >> Libkmod honors ‘modprobe.blacklist’ (in ‘kcmdline_parse_result’ in >> libkmod-config.c) and eudev passes KMOD_PROBE_APPLY_BLACKLIST >> unconditionally in udev-builtin-kmod.c (meaning it honors it too.) >>

bug#22633: Provide a kvm-less qemu / guix system vm

Jookia writes: > On Mon, Feb 22, 2016 at 11:35:30AM -0800, Christopher Allan Webber wrote: >>#~(string-append >> - " -enable-kvm -no-reboot -net nic,model=virtio \ >> + ;; Only enable kvm if we see /dev/kvm exists. >> + ;; This allows uers without

bug#22633: Provide a kvm-less qemu / guix system vm

Ludovic Courtès writes: > Christopher Allan Webber skribis: > >> Christopher Allan Webber writes: >> >>> Ludovic Courtès writes: >>> >>>> Libkmod honors ‘modprobe.blacklist’ (in ‘kcmdline_parse_result’ in >>>> libkmod-config.c) and eud

bug#22808: Add a function to simplify many of the new python2-foo definitions

Right now we have a lot of these that look very similar: (define-public python2-chardet (package (inherit (package-with-python2 (strip-python2-variant python-chardet))) (native-inputs `(("python2-setuptools" ,python2-setuptools) (define-public python2-trans

bug#22858: Patch security vulnerability in python-pillow

See: https://lwn.net/Articles/677914/ > Package: pillow > CVE ID : CVE-2016-0740 CVE-2016-0775 CVE-2016-2533 > > Multiple security vulnerabilities have been found in Pillow, a Python > imaging library, which may result in denial of service or the execution > of arbitrary code if

bug#22858: Patch security vulnerability in python-pillow

Should we remove it? I think so. Here's a patch to remove it. Look good? (Not sure if this needs a review or not :)) - Chris >From cbeb28d364bf2df3ef95c547b80830611254fd5c Mon Sep 17 00:00:00 2001 From: Christopher Allan Webber Date: Mon, 29 Feb 2016 14:36:01 -0800 Subject: [PATC

bug#22858: Patch security vulnerability in python-pillow

Christopher Allan Webber writes: > Leo Famulari writes: > >>> I'm trying to figure out where the patches for this are, but I can't >>> find them. I expected them to maybe be here, but I don't see them here: >> >> I updated python-pillow to 3.1.1

bug#22868: letsencrypt certs don't work for git repositories

See: $ git clone https://git.dthompson.us/presentations.git davexunit-presentations Cloning into 'davexunit-presentations'... fatal: unable to access 'https://git.dthompson.us/presentations.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

bug#22876: Python can't use https with recent grafts

Most of Guix seems to be working just fine with the grafts support and grafting of openssl. However, unlike most grafts that will be done probably, this one removes a feature, and that seems to be creating problems in Python land. >>> from urllib.request import HTTPSHandler Traceback (most re

bug#22876: Python can't use https with recent grafts

Christopher Allan Webber writes: > Most of Guix seems to be working just fine with the grafts support and > grafting of openssl. However, unlike most grafts that will be done > probably, this one removes a feature, and that seems to be creating > problems in Python land. &g

bug#22883: Trustable "guix pull"

Right now, when a user does a "guix pull", that pulls down the latest repository of code from git, which is kept in a tarball. Once you receive the latest code, this has some checks: what's the hash of each package, etc. Unfortunately, it's delivered over http: (define %snapshot-url ;; "ht

bug#22738: Build failure in vigra

Andreas Enge writes: > On Thu, Feb 18, 2016 at 10:59:11PM -0500, Leo Famulari wrote: >> It looks like we need this module 'vigranumpy': >> https://ukoethe.github.io/vigra/doc-release/vigranumpy/index.html > > This is part of the vigra source code. There should soon be a new vigra > release: >

bug#22883: Trustable "guix pull"

Leo Famulari writes: > On Wed, Mar 02, 2016 at 10:03:59AM -0800, Christopher Allan Webber wrote: >> Right now, when a user does a "guix pull", that pulls down the latest >> repository of code from git, which is kept in a tarball. Once you >> receive the latest cod

bug#22965: git guix build error in ./pre-inst-env guix environment guix

Closing the bug.

bug#23103: A number of corrupt packages on Hydra?

For at least boost and hydra I'm getting errors like the following: From http://hydra.gnunet.org/nar/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0 Downloading jaf2s3...-ruby-2.3.0 (41.9MiB installed)... http://hydra.gnunet.org/nar/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0 2.0MiB/s 00:02 |

bug#23103: A number of corrupt packages on Hydra?

Allegedly, Ludo has fixed this, or at least https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01039.html makes it sound like it :)

bug#23256: vlc not building after update to ffmpeg 3.0

vlc is failing to build after the update recently to ffmpeg 3.0. I verified that it builds prior to this change. Should we include an older version of ffmpeg to build vlc with for now? Or should we try to figure out what to do to to get vlc to build with ffmpeg 3.0? Maybe for now we should do th

bug#23256: vlc not building after update to ffmpeg 3.0

Christopher Allan Webber writes: > vlc is failing to build after the update recently to ffmpeg 3.0. I > verified that it builds prior to this change. > > Should we include an older version of ffmpeg to build vlc with for now? > Or should we try to figure out what to do to to g

bug#22883: Authenticating a Git checkout

Ludovic Courtès writes: >>> Second, even if it did, it would be a shallow check: as Mike notes in >>> with the ‘signchk’ >>> script, you actually have to traverse the whole commit history and >>> authenticate them one by one. But that’s OK, it run

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

Ludovic Courtès writes: > Hello Felipe! > > Luis Felipe López Acevedo skribis: > >> Steps to reproduce >> == >> >> 1. Go to https://www.gnu.org/software/guix/packages/g.html >> 2. Locate a guix package, and click on the "Expand" button >> >> >> Unexpected behavior >> =

bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes

Hello! I'm getting this error while trying to compile latest guix master on one of my machines (fortunately, not my main one). I don't know why I'm hitting this error, since I'm not hitting it on my main machine. I'm upgrading from a few months back. I spoke on irc and found that Ricardo had th

bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes

Marius Bakke writes: > Which kernel version is this? Linux-Libre 4.8.1 And! As it turns out, I went to the last revision before I was hitting compilation isues (c90db25f4cf1f98f3f4f3af38d175a14ffb8c32a), did a make on the repo, and from there I did a "guix system reconfigure". I restarted, an

bug#26608: Provide --only-substitutes flag to "guix package --upgrade"

Sometimes I do an upgrade and I want to get the latest security updates, but I also am not really available to burn through a lot of cpu time, (especially on my x200). I'd love it if thre were a flag so that I could specify "only bother to upgrade the packages where we only upgrade if a substitute

bug#26610: python-gpg broke; python-gpg 1.9.0 does not exist

Commit 8439c9c05e upgraded gpgme to 1.9.0. Unfortunately, python-gpg's version is tied to gpgme: (define-public python-gpg (package (name "python-gpg") (version (package-version gpgme)) ;; [...] This is a problem, because upgrading gpgme "automatically" upgraded python-gpg, and the

bug#26695: openssh password-authentication? should be #f by default

Our default permits password authentication for the openssh service (and the others it seems) by default in Guix. This is somewhat dangerous because this is a much easier to break in this way, and some users might not assume the default is reasonably safe. If users really want password-authentica

bug#26696: openssh: root 'without-password & password-authentication #f both breaks service

I wanted to permit root logins but only permit public key authentication in my openssh configuration. This was my original assumption of how to do it: (service openssh-service-type (openssh-configuration (permit-root-login 'without-password) (password-authenticat

bug#26695: openssh password-authentication? should be #f by default

Maxim Cournoyer writes: > +1. Although it means the keys will have to be copied by another mean > than the "ssh-copy-id" script. Maybe the configuration could accept > the public key? :) I haven't checked if this is already possible. We have discussed in the past having some service that just cop

bug#26695: openssh password-authentication? should be #f by default

Marius Bakke writes: >> We have discussed in the past having some service that just copies some >> static files on init. That would be enough to set up public keys >> appropriately. > > I think that can already be done with 'special-file-service-type'. > > https://lists.gnu.org/archive/html/guix-

bug#26917: [PATCH] Add thermald and thermald-service-type (for cpu frequency scaling)

Hello! I got tired of my laptop crashing so much due to overheating, so here's a package for thermald as well as a service type. >From 56c7019d58d4a064fe44e626a1396b62cbf808b0 Mon Sep 17 00:00:00 2001 From: Christopher Allan Webber Date: Sat, 13 May 2017 19:36:01 -0500 Subject: [PATCH

bug#26917: [PATCH] Add thermald and thermald-service-type (for cpu frequency scaling)

Bah, this should have been sent to guix-patches. Christopher Allan Webber writes: > Hello! I got tired of my laptop crashing so much due to overheating, so > here's a package for thermald as well as a service type. > >>From 56c7019d58d4a064fe44e626a1396b62cbf808b0 Mon

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

Clément Lassieur writes: > Clément Lassieur writes: > >>> I just flashed the latest stable of libreboot and for t400 it is fixed, >>> I can recover from suspend. Thanks to the amazing work of Leah and all >>> other libreboot contributors :) >> >> I still reproduce the bug with latest stable and x

bug#27795: Issues with upstream source for guile-emacs

Leo Famulari writes: > On Sun, Jul 23, 2017 at 04:22:06PM +0200, Ricardo Wurmus wrote: >> >> Ricardo Wurmus writes: >> >> > Leo Famulari writes: >> > >> >> While working on the bug 'Changing package source URLs from git:// to >> >> https://' [0], I noticed an issue with the sources for guile-ema

bug#28193: tome4 tiles are nonfree?

I was excited to see tome4 packaged for Guix since that game is *incredible*. However, I'm not totally sure about the music, but as for the tiles, there's this message in tome4's COPYING-MEDIA which says: All the medias located in all the "/data/gfx" folders are granted to use with the Tales

bug#28193: tome4 tiles are nonfree?

Mark H Weaver writes: > Hi Chris, > > Christopher Allan Webber writes: > >> I was excited to see tome4 packaged for Guix since that game is >> *incredible*. However, I'm not totally sure about the music, but as for >> the tiles, there's this mes

bug#28193: tome4 tiles are nonfree?

Christopher Allan Webber writes: >> Thanks for bringing this to our attention. The GNU FSDG requirements >> for non-functional data are relatively permissive: >> >> Non-functional Data >> >> Data that isn't functional, that doesn't do a prac

bug#28578: xorg not starting on x200 due to recent commit

The following commit to guix makes it so that I can't start xorg: c68c201fdd429140da1c606861c9296b9cb01265 Author: Andy Wingo CommitDate: Wed Sep 20 15:40:31 2017 +0200 gnu: xorg-server: Prefer intel driver only for older GPUs. * gnu/packages/xorg.scm (xorg-server): Add patch to o

bug#28578: xorg not starting on x200 due to recent commit

Chris Marusich writes: > Christopher Allan Webber writes: > >> The following commit to guix makes it so that I can't start xorg: >> >> c68c201fdd429140da1c606861c9296b9cb01265 >> Author: Andy Wingo >> CommitDate: Wed Sep 20 15:40:31 2017 +0200

bug#28578: xorg not starting on x200 due to recent commit

Chris Marusich writes: > Leo Famulari writes: > >> On Sun, Sep 24, 2017 at 05:15:02PM -0700, Chris Marusich wrote: >>> Christopher Allan Webber writes: >>> >>> > The following commit to guix makes it so that I can't start xorg: >>