all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Building Docker images of GuixSD
Date: Fri, 17 Nov 2017 22:14:54 +0100	[thread overview]
Message-ID: <87a7zk38vl.fsf@gnu.org> (raw)
In-Reply-To: <87y3ngvuyd.fsf@gmail.com> (Chris Marusich's message of "Wed, 08 Nov 2017 22:15:38 -0800")

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> Run GuixSD in Docker
> ====================
>
> The attached patch makes it possible to build a GuixSD Docker image from
> an operating system configuration file.

For some reason, I had overlooked this message, but it’s awesome!

> Pretty neat!

Yup!

> Problems I Noticed
> ==================

[...]

> Second, I noticed the following error in the Guix daemon's logs.  It
> might be benign, since package installation worked fine, but I'm not
> sure what it means or how to debug it:
>
>     error in finalization thread: Bad file descriptor

I’ve noticed this since we use Shepherd on Guile 2.2, but I haven’t
checked where that comes from; it doesn’t seem to be a serious issue.
;-)  Anyway, it’s not related to your experiment.

> Third, I noticed that the shepherd failed to start syslogd and nscd (and
> user-homes, although I wasn't as concerned about that because the home
> directory for alice did in fact get created).

[...]

> I thought maybe syslogd wasn't working because /dev/log hadn't been
> created in the Docker image, so I tried creating it manually.  However,
> that didn't help; the Shepherd still couldn't start syslogd.

Hmm, I would have thought /dev/log was the issue.  Any other hints?

> Fourth, I wasn't able to run GuixSD in a Docker container without
> supplying the "--privileged" option.  GuixSD writes to sysfs during boot
> (I don't know why, but the details are apparently in
> guix/gnu/build/activation.scm), so the only way to get GuixSD to start
> is to run the container in privileged mode.  This is unfortunate,
> because privileged mode sounds quite dangerous for a lot of reasons.

I don’t think so: there’s a special case for when one creates a
container with ‘guix system container’ that disables this kind of thing.
I guess we should use it here.  It’s mostly about passing #:container? #f 
somewhere.

> From 25d5527b14302fc835af5c338bf37cf621c63a4e Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich@gmail.com>
> Date: Sat, 21 Oct 2017 14:40:58 -0700
> Subject: [PATCH] Make it possible to build GuixSD docker images
>
> ---
>  gnu/build/linux-boot.scm    |   5 +-
>  gnu/build/vm.scm            |  14 ++--
>  gnu/system/linux-initrd.scm |  12 ++--
>  gnu/system/vm.scm           | 169 ++++++++++++++++++++++++++++++++++++++------
>  guix/docker.scm             |  23 ++++--
>  guix/scripts/pack.scm       |   5 +-
>  guix/scripts/system.scm     |   3 +-
>  7 files changed, 191 insertions(+), 40 deletions(-)

[...]

> +      (cond ((string=? "iso9660" file-system-type)
> +             (iso9660-image #:name name
> +                            #:file-system-label root-label
> +                            #:file-system-uuid root-uuid
> +                            #:os-drv os-drv
> +                            #:register-closures? #t
> +                            #:bootcfg-drv bootcfg
> +                            #:bootloader (bootloader-configuration-bootloader
> +                                           (operating-system-bootloader os))
> +                            #:inputs `(("system" ,os-drv)
> +                                       ("bootcfg" ,bootcfg))))
> +            ((string=? "docker" file-system-type)
> +             (display "made it to docker image part\n")
> +             (os-docker-image #:name name
> +                              #:os-drv os-drv
> +                              #:register-closures? #t))

I’m not sure this is the right place for it since “docker” is not a file
system type.  Perhaps we need a separate procedure instead?

> @@ -106,7 +107,9 @@ return \"a\"."
>                               #:key closure compressor
>                               (symlinks '())
>                               (system (utsname:machine (uname)))
> -                             (creation-time (current-time time-utc)))
> +                             (creation-time (current-time time-utc))
> +                             (tmpdir "/tmp")
> +                             extra-items-dir)
>    "Write to IMAGE a Docker image archive from the given store PATH.  The image
>  contains the closure of PATH, as specified in CLOSURE (a file produced by
>  #:references-graphs).  SYMLINKS must be a list of (SOURCE -> TARGET) tuples
> @@ -116,7 +119,7 @@ binaries at PATH are for; it is used to produce metadata in the image.
>  
>  Use COMPRESSOR, a command such as '(\"gzip\" \"-9n\"), to compress IMAGE.  Use
>  CREATION-TIME, a SRFI-19 time-utc object, as the creation time in metadata."
> -  (let ((directory "/tmp/docker-image")           ;temporary working directory
> +  (let ((directory (string-append tmpdir "/docker-image")) ;temporary working directory

Why do we need that?  Would it be enough to honor $TMPDIR?

> --- a/guix/scripts/system.scm
> +++ b/guix/scripts/system.scm
> @@ -638,8 +638,9 @@ any, are available.  Raise an error if they're not."
>                                              #:mappings mappings))
>      ((disk-image)
>       (system-disk-image os
> -                        #:name (match file-system-type
> +                        #:name (match (pk file-system-type)
>                                   ("iso9660" "image.iso")
> +                                 ("docker" "docker-image")
>                                   (_         "disk-image"))
>                          #:disk-image-size image-size
>                          #:file-system-type file-system-type))))

Perhaps we could have a separate ‘guix system docker-image’ command?  Or
‘guix system container -f docker’?  WDYT?

Once we’ve sorted out these minor issues, it would be great if you could
send polished patches.  This is something we should add!

Thank you,
Ludo’.

  parent reply	other threads:[~2017-11-17 21:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12  3:29 Guix on macOS Chris Marusich
2017-10-12  8:08 ` Konrad Hinsen
2017-10-12  8:59 ` Ludovic Courtès
2017-10-12 20:35   ` Christopher Allan Webber
2017-10-12 21:33   ` Ricardo Wurmus
2017-10-13 15:58     ` Christopher Allan Webber
2017-10-13  7:14   ` Chris Marusich
2017-10-13 11:47     ` Ricardo Wurmus
2017-10-13 12:55     ` Ludovic Courtès
2017-10-13 13:59       ` Konrad Hinsen
2017-10-13 13:59       ` Ricardo Wurmus
2017-10-13 15:59         ` Christopher Allan Webber
2017-10-13 14:08       ` Konrad Hinsen
2017-10-25 15:50         ` Adonay Felipe Nogueira
2017-10-27  4:11     ` Chris Marusich
2017-10-27  7:56       ` Hartmut Goebel
2017-10-28 20:27       ` Building Docker images of GuixSD Ludovic Courtès
2017-10-31  2:59         ` Chris Marusich
2017-11-05 15:45           ` Ludovic Courtès
2017-11-09  6:15             ` Chris Marusich
2017-11-09  6:43               ` Pjotr Prins
2017-11-09  8:23               ` Konrad Hinsen
2017-11-17 21:14               ` Ludovic Courtès [this message]
2017-11-27 22:13               ` Christopher Baines
2017-11-30  9:11                 ` Ludovic Courtès
2017-12-07  9:33                 ` Chris Marusich
2017-12-16  2:30                 ` Chris Marusich
2017-10-12 19:09 ` Guix on macOS Christopher Baines
2017-10-25 14:45 ` Adonay Felipe Nogueira
2017-10-27  1:06   ` Chris Marusich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7zk38vl.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.