guix.texi

\input texinfo
@c -*-texinfo-*-

@c %**start of header
@setfilename guix.info
@documentencoding UTF-8
@settitle GNU Guix Reference Manual
@c %**end of header

@include version.texi

@c Identifier of the OpenPGP key used to sign tarballs and such.
@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
@set OPENPGP-SIGNING-KEY-URL https://sv.gnu.org/people/viewgpg.php?user_id=15145

@c Base URL for downloads.
@set BASE-URL https://ftp.gnu.org/gnu/guix

@c The official substitute server used by default.
@set SUBSTITUTE-SERVER ci.guix.gnu.org
@set SUBSTITUTE-URL https://@value{SUBSTITUTE-SERVER}

@copying
Copyright @copyright{} 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès@*
Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@*
Copyright @copyright{} 2013 Nikita Karetnikov@*
Copyright @copyright{} 2014, 2015, 2016 Alex Kost@*
Copyright @copyright{} 2015, 2016 Mathieu Lirzin@*
Copyright @copyright{} 2014 Pierre-Antoine Rault@*
Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
Copyright @copyright{} 2015, 2016, 2017, 2019 Leo Famulari@*
Copyright @copyright{} 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus@*
Copyright @copyright{} 2016 Ben Woodcroft@*
Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@*
Copyright @copyright{} 2016, 2017, 2018, 2019 Efraim Flashner@*
Copyright @copyright{} 2016 John Darrington@*
Copyright @copyright{} 2016, 2017 ng0@*
Copyright @copyright{} 2016, 2017, 2018, 2019 Jan Nieuwenhuizen@*
Copyright @copyright{} 2016 Julien Lepiller@*
Copyright @copyright{} 2016 Alex ter Weele@*
Copyright @copyright{} 2016, 2017, 2018, 2019 Christopher Baines@*
Copyright @copyright{} 2017, 2018 Clément Lassieur@*
Copyright @copyright{} 2017, 2018 Mathieu Othacehe@*
Copyright @copyright{} 2017 Federico Beffa@*
Copyright @copyright{} 2017, 2018 Carlo Zancanaro@*
Copyright @copyright{} 2017 Thomas Danckaert@*
Copyright @copyright{} 2017 humanitiesNerd@*
Copyright @copyright{} 2017 Christopher Allan Webber@*
Copyright @copyright{} 2017, 2018 Marius Bakke@*
Copyright @copyright{} 2017 Hartmut Goebel@*
Copyright @copyright{} 2017 Maxim Cournoyer@*
Copyright @copyright{} 2017, 2018, 2019 Tobias Geerinckx-Rice@*
Copyright @copyright{} 2017 George Clemmer@*
Copyright @copyright{} 2017 Andy Wingo@*
Copyright @copyright{} 2017, 2018, 2019 Arun Isaac@*
Copyright @copyright{} 2017 nee@*
Copyright @copyright{} 2018 Rutger Helling@*
Copyright @copyright{} 2018 Oleg Pykhalov@*
Copyright @copyright{} 2018 Mike Gerwitz@*
Copyright @copyright{} 2018 Pierre-Antoine Rouby@*
Copyright @copyright{} 2018, 2019 Gábor Boskovits@*
Copyright @copyright{} 2018, 2019 Florian Pelz@*
Copyright @copyright{} 2018 Laura Lazzati@*
Copyright @copyright{} 2018 Alex Vong@*
Copyright @copyright{} 2019 Josh Holland@*
Copyright @copyright{} 2019 Diego Nicola Barbato@*
Copyright @copyright{} 2019 Ivan Petkov@*
Copyright @copyright{} 2019 Jakob L. Kreuze@*

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
copy of the license is included in the section entitled ``GNU Free
Documentation License''.
@end copying

@dircategory System administration
@direntry
* Guix: (guix).       Manage installed software and system configuration.
* guix package: (guix)Invoking guix package.  Installing, removing, and upgrading packages.
* guix gc: (guix)Invoking guix gc.            Reclaiming unused disk space.
* guix pull: (guix)Invoking guix pull.        Update the list of available packages.
* guix system: (guix)Invoking guix system.    Manage the operating system configuration.
* guix deploy: (guix)Invoking guix deploy.    Manage operating system configurations for remote hosts.
@end direntry

@dircategory Software development
@direntry
* guix environment: (guix)Invoking guix environment. Building development environments with Guix.
* guix build: (guix)Invoking guix build.      Building packages.
* guix pack: (guix)Invoking guix pack.        Creating binary bundles.
@end direntry

@titlepage
@title GNU Guix Reference Manual
@subtitle Using the GNU Guix Functional Package Manager
@author The GNU Guix Developers

@page
@vskip 0pt plus 1filll
Edition @value{EDITION} @*
@value{UPDATED} @*

@insertcopying
@end titlepage

@contents

@c *********************************************************************
@node Top
@top GNU Guix

This document describes GNU Guix version @value{VERSION}, a functional
package management tool written for the GNU system.

@c TRANSLATORS: You can replace the following paragraph with information on
@c how to join your own translation team and how to report issues with the
@c translation.
This manual is also available in Simplified Chinese (@pxref{Top,,, guix.zh_CN,
GNU Guix参考手册}), French (@pxref{Top,,, guix.fr, Manuel de référence de GNU
Guix}), German (@pxref{Top,,, guix.de, Referenzhandbuch zu GNU Guix}),
Spanish (@pxref{Top,,, guix.es, Manual de referencia de GNU Guix}), and
Russian (@pxref{Top,,, guix.ru, Руководство GNU Guix}).  If you
would like to translate it in your native language, consider joining the
@uref{https://translationproject.org/domain/guix-manual.html, Translation
Project}.

@menu
* Introduction::                What is Guix about?
* Installation::                Installing Guix.
* System Installation::         Installing the whole operating system.
* Package Management::          Package installation, upgrade, etc.
* Development::                 Guix-aided software development.
* Programming Interface::       Using Guix in Scheme.
* Utilities::                   Package management commands.
* System Configuration::        Configuring the operating system.
* Documentation::               Browsing software user manuals.
* Installing Debugging Files::  Feeding the debugger.
* Security Updates::            Deploying security fixes quickly.
* Bootstrapping::               GNU/Linux built from scratch.
* Porting::                     Targeting another platform or kernel.
* Contributing::                Your help needed!

* Acknowledgments::             Thanks!
* GNU Free Documentation License::  The license of this manual.
* Concept Index::               Concepts.
* Programming Index::           Data types, functions, and variables.

@detailmenu
 --- The Detailed Node Listing ---

Introduction

* Managing Software the Guix Way::      What's special.
* GNU Distribution::                    The packages and tools.

Installation

* Binary Installation::         Getting Guix running in no time!
* Requirements::                Software needed to build and run Guix.
* Running the Test Suite::      Testing Guix.
* Setting Up the Daemon::       Preparing the build daemon's environment.
* Invoking guix-daemon::        Running the build daemon.
* Application Setup::           Application-specific setup.

Setting Up the Daemon

* Build Environment Setup::     Preparing the isolated build environment.
* Daemon Offload Setup::        Offloading builds to remote machines.
* SELinux Support::             Using an SELinux policy for the daemon.

System Installation

* Limitations::                 What you can expect.
* Hardware Considerations::     Supported hardware.
* USB Stick and DVD Installation::  Preparing the installation medium.
* Preparing for Installation::  Networking, partitioning, etc.
* Guided Graphical Installation::  Easy graphical installation.
* Manual Installation::         Manual installation for wizards.
* After System Installation::   When installation succeeded.
* Installing Guix in a VM::     Guix System playground.
* Building the Installation Image::  How this comes to be.

Manual Installation

* Keyboard Layout and Networking and Partitioning:: Initial setup.
* Proceeding with the Installation::  Installing.

Package Management

* Features::                    How Guix will make your life brighter.
* Invoking guix package::       Package installation, removal, etc.
* Substitutes::                 Downloading pre-built binaries.
* Packages with Multiple Outputs::  Single source package, multiple outputs.
* Invoking guix gc::            Running the garbage collector.
* Invoking guix pull::          Fetching the latest Guix and distribution.
* Channels::                    Customizing the package collection.
* Inferiors::                   Interacting with another revision of Guix.
* Invoking guix describe::      Display information about your Guix revision.
* Invoking guix archive::       Exporting and importing store files.

Substitutes

* Official Substitute Server::  One particular source of substitutes.
* Substitute Server Authorization::  How to enable or disable substitutes.
* Substitute Authentication::   How Guix verifies substitutes.
* Proxy Settings::              How to get substitutes via proxy.
* Substitution Failure::        What happens when substitution fails.
* On Trusting Binaries::        How can you trust that binary blob?

Development

* Invoking guix environment::   Setting up development environments.
* Invoking guix pack::          Creating software bundles.

Programming Interface

* Package Modules::             Packages from the programmer's viewpoint.
* Defining Packages::           Defining new packages.
* Build Systems::               Specifying how packages are built.
* The Store::                   Manipulating the package store.
* Derivations::                 Low-level interface to package derivations.
* The Store Monad::             Purely functional interface to the store.
* G-Expressions::               Manipulating build expressions.
* Invoking guix repl::          Fiddling with Guix interactively.

Defining Packages

* package Reference::           The package data type.
* origin Reference::            The origin data type.

Utilities

* Invoking guix build::         Building packages from the command line.
* Invoking guix edit::          Editing package definitions.
* Invoking guix download::      Downloading a file and printing its hash.
* Invoking guix hash::          Computing the cryptographic hash of a file.
* Invoking guix import::        Importing package definitions.
* Invoking guix refresh::       Updating package definitions.
* Invoking guix lint::          Finding errors in package definitions.
* Invoking guix size::          Profiling disk usage.
* Invoking guix graph::         Visualizing the graph of packages.
* Invoking guix publish::       Sharing substitutes.
* Invoking guix challenge::     Challenging substitute servers.
* Invoking guix copy::          Copying to and from a remote store.
* Invoking guix container::     Process isolation.
* Invoking guix weather::       Assessing substitute availability.
* Invoking guix processes::     Listing client processes.

Invoking @command{guix build}

* Common Build Options::        Build options for most commands.
* Package Transformation Options::  Creating variants of packages.
* Additional Build Options::    Options specific to 'guix build'.
* Debugging Build Failures::    Real life packaging experience.

System Configuration

* Using the Configuration System::  Customizing your GNU system.
* operating-system Reference::  Detail of operating-system declarations.
* File Systems::                Configuring file system mounts.
* Mapped Devices::              Block device extra processing.
* User Accounts::               Specifying user accounts.
* Keyboard Layout::             How the system interprets key strokes.
* Locales::                     Language and cultural convention settings.
* Services::                    Specifying system services.
* Setuid Programs::             Programs running with root privileges.
* X.509 Certificates::          Authenticating HTTPS servers.
* Name Service Switch::         Configuring libc's name service switch.
* Initial RAM Disk::            Linux-Libre bootstrapping.
* Bootloader Configuration::    Configuring the boot loader.
* Invoking guix system::        Instantiating a system configuration.
* Invoking guix deploy::        Deploying a system configuration to a remote host.
* Running Guix in a VM::        How to run Guix System in a virtual machine.
* Defining Services::           Adding new service definitions.

Services

* Base Services::               Essential system services.
* Scheduled Job Execution::     The mcron service.
* Log Rotation::                The rottlog service.
* Networking Services::         Network setup, SSH daemon, etc.
* X Window::                    Graphical display.
* Printing Services::           Local and remote printer support.
* Desktop Services::            D-Bus and desktop services.
* Sound Services::              ALSA and Pulseaudio services.
* Database Services::           SQL databases, key-value stores, etc.
* Mail Services::               IMAP, POP3, SMTP, and all that.
* Messaging Services::          Messaging services.
* Telephony Services::          Telephony services.
* Monitoring Services::         Monitoring services.
* Kerberos Services::           Kerberos services.
* Web Services::                Web servers.
* Certificate Services::        TLS certificates via Let's Encrypt.
* DNS Services::                DNS daemons.
* VPN Services::                VPN daemons.
* Network File System::         NFS related services.
* Continuous Integration::      The Cuirass service.
* Power Management Services::   Extending battery life.
* Audio Services::              The MPD.
* Virtualization Services::     Virtualization services.
* Version Control Services::    Providing remote access to Git repositories.
* Game Services::               Game servers.
* Miscellaneous Services::      Other services.

Defining Services

* Service Composition::         The model for composing services.
* Service Types and Services::  Types and services.
* Service Reference::           API reference.
* Shepherd Services::           A particular type of service.

@end detailmenu
@end menu

@c *********************************************************************
@node Introduction
@chapter Introduction

@cindex purpose
GNU Guix@footnote{``Guix'' is pronounced like ``geeks'', or ``ɡiːks''
using the international phonetic alphabet (IPA).} is a package
management tool for and distribution of the GNU system.
Guix makes it easy for unprivileged
users to install, upgrade, or remove software packages, to roll back to a
previous package set, to build packages from source, and generally
assists with the creation and maintenance of software environments.

@cindex Guix System
@cindex GuixSD, now Guix System
@cindex Guix System Distribution, now Guix System
You can install GNU@tie{}Guix on top of an existing GNU/Linux system where it
complements the available tools without interference (@pxref{Installation}),
or you can use it as a standalone operating system distribution,
@dfn{Guix@tie{}System}@footnote{We used to refer to Guix System as ``Guix
System Distribution'' or ``GuixSD''.  We now consider it makes more sense to
group everything under the ``Guix'' banner since, after all, Guix System is
readily available through the @command{guix system} command, even if you're
using a different distro underneath!}.  @xref{GNU Distribution}.

@menu
* Managing Software the Guix Way::      What's special.
* GNU Distribution::                    The packages and tools.
@end menu

@node Managing Software the Guix Way
@section Managing Software the Guix Way

@cindex user interfaces
Guix provides a command-line package management interface
(@pxref{Package Management}), tools to help with software development
(@pxref{Development}), command-line utilities for more advanced usage,
(@pxref{Utilities}), as well as Scheme programming interfaces
(@pxref{Programming Interface}).
@cindex build daemon
Its @dfn{build daemon} is responsible for building packages on behalf of
users (@pxref{Setting Up the Daemon}) and for downloading pre-built
binaries from authorized sources (@pxref{Substitutes}).

@cindex extensibility of the distribution
@cindex customization, of packages
Guix includes package definitions for many GNU and non-GNU packages, all
of which @uref{https://www.gnu.org/philosophy/free-sw.html, respect the
user's computing freedom}.  It is @emph{extensible}: users can write
their own package definitions (@pxref{Defining Packages}) and make them
available as independent package modules (@pxref{Package Modules}).  It
is also @emph{customizable}: users can @emph{derive} specialized package
definitions from existing ones, including from the command line
(@pxref{Package Transformation Options}).

@cindex functional package management
@cindex isolation
Under the hood, Guix implements the @dfn{functional package management}
discipline pioneered by Nix (@pxref{Acknowledgments}).
In Guix, the package build and installation process is seen
as a @emph{function}, in the mathematical sense.  That function takes inputs,
such as build scripts, a compiler, and libraries, and
returns an installed package.  As a pure function, its result depends
solely on its inputs---for instance, it cannot refer to software or
scripts that were not explicitly passed as inputs.  A build function
always produces the same result when passed a given set of inputs.  It
cannot alter the environment of the running system in
any way; for instance, it cannot create, modify, or delete files outside
of its build and installation directories.  This is achieved by running
build processes in isolated environments (or @dfn{containers}), where only their
explicit inputs are visible.

@cindex store
The result of package build functions is @dfn{cached} in the file
system, in a special directory called @dfn{the store} (@pxref{The
Store}).  Each package is installed in a directory of its own in the
store---by default under @file{/gnu/store}.  The directory name contains
a hash of all the inputs used to build that package; thus, changing an
input yields a different directory name.

This approach is the foundation for the salient features of Guix: support
for transactional package upgrade and rollback, per-user installation, and
garbage collection of packages (@pxref{Features}).


@node GNU Distribution
@section GNU Distribution

@cindex Guix System
Guix comes with a distribution of the GNU system consisting entirely of
free software@footnote{The term ``free'' here refers to the
@url{https://www.gnu.org/philosophy/free-sw.html,freedom provided to
users of that software}.}.  The
distribution can be installed on its own (@pxref{System Installation}),
but it is also possible to install Guix as a package manager on top of
an installed GNU/Linux system (@pxref{Installation}).  When we need to
distinguish between the two, we refer to the standalone distribution as
Guix@tie{}System.

The distribution provides core GNU packages such as GNU libc, GCC, and
Binutils, as well as many GNU and non-GNU applications.  The complete
list of available packages can be browsed
@url{https://www.gnu.org/software/guix/packages,on-line} or by
running @command{guix package} (@pxref{Invoking guix package}):

@example
guix package --list-available
@end example

Our goal is to provide a practical 100% free software distribution of
Linux-based and other variants of GNU, with a focus on the promotion and
tight integration of GNU components, and an emphasis on programs and
tools that help users exert that freedom.

Packages are currently available on the following platforms:

@table @code

@item x86_64-linux
Intel/AMD @code{x86_64} architecture, Linux-Libre kernel;

@item i686-linux
Intel 32-bit architecture (IA32), Linux-Libre kernel;

@item armhf-linux
ARMv7-A architecture with hard float, Thumb-2 and NEON,
using the EABI hard-float application binary interface (ABI),
and Linux-Libre kernel.

@item aarch64-linux
little-endian 64-bit ARMv8-A processors, Linux-Libre kernel.

@item mips64el-linux
little-endian 64-bit MIPS processors, specifically the Loongson series,
n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
supported; in particular, the project's build farms no longer provide
substitutes for this architecture.

@end table

With Guix@tie{}System, you @emph{declare} all aspects of the operating system
configuration and Guix takes care of instantiating the configuration in a
transactional, reproducible, and stateless fashion (@pxref{System
Configuration}).  Guix System uses the Linux-libre kernel, the Shepherd
initialization system (@pxref{Introduction,,, shepherd, The GNU Shepherd
Manual}), the well-known GNU utilities and tool chain, as well as the
graphical environment or system services of your choice.

Guix System is available on all the above platforms except
@code{mips64el-linux}.

@noindent
For information on porting to other architectures or kernels,
@pxref{Porting}.

Building this distribution is a cooperative effort, and you are invited
to join!  @xref{Contributing}, for information about how you can help.


@c *********************************************************************
@node Installation
@chapter Installation

@cindex installing Guix

@quotation Note
We recommend the use of this
@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
shell installer script} to install Guix on top of a running GNU/Linux system,
thereafter called a @dfn{foreign distro}.@footnote{This section is concerned
with the installation of the package manager, which can be done on top of a
running GNU/Linux system.  If, instead, you want to install the complete GNU
operating system, @pxref{System Installation}.} The script automates the
download, installation, and initial configuration of Guix.  It should be run
as the root user.
@end quotation

@cindex foreign distro
@cindex directories related to foreign distro
When installed on a foreign distro, GNU@tie{}Guix complements the available
tools without interference.  Its data lives exclusively in two directories,
usually @file{/gnu/store} and @file{/var/guix}; other files on your system,
such as @file{/etc}, are left untouched.

Once installed, Guix can be updated by running @command{guix pull}
(@pxref{Invoking guix pull}).

If you prefer to perform the installation steps manually or want to tweak
them, you may find the following subsections useful.  They describe the
software requirements of Guix, as well as how to install it manually and get
ready to use it.

@menu
* Binary Installation::         Getting Guix running in no time!
* Requirements::                Software needed to build and run Guix.
* Running the Test Suite::      Testing Guix.
* Setting Up the Daemon::       Preparing the build daemon's environment.
* Invoking guix-daemon::        Running the build daemon.
* Application Setup::           Application-specific setup.
@end menu

@node Binary Installation
@section Binary Installation

@cindex installing Guix from binaries
@cindex installer script
This section describes how to install Guix on an arbitrary system from a
self-contained tarball providing binaries for Guix and for all its
dependencies.  This is often quicker than installing from source, which
is described in the next sections.  The only requirement is to have
GNU@tie{}tar and Xz.

@c Note duplicated from the ``Installation'' node.
@quotation Note
We recommend the use of this
@uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh,
shell installer script}.  The script automates the download, installation, and
initial configuration steps described below.  It should be run as the root
user.
@end quotation

Installing goes along these lines:

@enumerate
@item
@cindex downloading Guix binary
Download the binary tarball from
@indicateurl{@value{BASE-URL}/guix-binary-@value{VERSION}.@var{system}.tar.xz},
where @var{system} is @code{x86_64-linux} for an @code{x86_64} machine
already running the kernel Linux, and so on.

@c The following is somewhat duplicated in ``System Installation''.
Make sure to download the associated @file{.sig} file and to verify the
authenticity of the tarball against it, along these lines:

@example
$ wget @value{BASE-URL}/guix-binary-@value{VERSION}.@var{system}.tar.xz.sig
$ gpg --verify guix-binary-@value{VERSION}.@var{system}.tar.xz.sig
@end example

If that command fails because you do not have the required public key,
then run this command to import it:

@example
$ wget @value{OPENPGP-SIGNING-KEY-URL} \
      -qO - | gpg --import -
@end example

@noindent
and rerun the @code{gpg --verify} command.

Take note that a warning like ``This key is not certified with a trusted
signature!'' is normal.

@c end authentication part

@item
Now, you need to become the @code{root} user.  Depending on your distribution,
you may have to run @code{su -} or @code{sudo -i}.  As @code{root}, run:

@example
# cd /tmp
# tar --warning=no-timestamp -xf \
     /path/to/guix-binary-@value{VERSION}.@var{system}.tar.xz
# mv var/guix /var/ && mv gnu /
@end example

This creates @file{/gnu/store} (@pxref{The Store}) and @file{/var/guix}.
The latter contains a ready-to-use profile for @code{root} (see next
step.)

Do @emph{not} unpack the tarball on a working Guix system since that
would overwrite its own essential files.

The @code{--warning=no-timestamp} option makes sure GNU@tie{}tar does
not emit warnings about ``implausibly old time stamps'' (such
warnings were triggered by GNU@tie{}tar 1.26 and older; recent
versions are fine.)
They stem from the fact that all the
files in the archive have their modification time set to zero (which
means January 1st, 1970.)  This is done on purpose to make sure the
archive content is independent of its creation time, thus making it
reproducible.

@item
Make the profile available under @file{~root/.config/guix/current}, which is
where @command{guix pull} will install updates (@pxref{Invoking guix pull}):

@example
# mkdir -p ~root/.config/guix
# ln -sf /var/guix/profiles/per-user/root/current-guix \
         ~root/.config/guix/current
@end example

Source @file{etc/profile} to augment @code{PATH} and other relevant
environment variables:

@example
# GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
  source $GUIX_PROFILE/etc/profile
@end example

@item
Create the group and user accounts for build users as explained below
(@pxref{Build Environment Setup}).

@item
Run the daemon, and set it to automatically start on boot.

If your host distro uses the systemd init system, this can be achieved
with these commands:

@c Versions of systemd that supported symlinked service files are not
@c yet widely deployed, so we should suggest that users copy the service
@c files into place.
@c
@c See this thread for more information:
@c https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html

@example
# cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
     /etc/systemd/system/
# systemctl start guix-daemon && systemctl enable guix-daemon
@end example

If your host distro uses the Upstart init system:

@example
# initctl reload-configuration
# cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \
     /etc/init/
# start guix-daemon
@end example

Otherwise, you can still start the daemon manually with:

@example
# ~root/.config/guix/current/bin/guix-daemon \
       --build-users-group=guixbuild
@end example

@item
Make the @command{guix} command available to other users on the machine,
for instance with:

@example
# mkdir -p /usr/local/bin
# cd /usr/local/bin
# ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
@end example

It is also a good idea to make the Info version of this manual available
there:

@example
# mkdir -p /usr/local/share/info
# cd /usr/local/share/info
# for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
  do ln -s $i ; done
@end example

That way, assuming @file{/usr/local/share/info} is in the search path,
running @command{info guix} will open this manual (@pxref{Other Info
Directories,,, texinfo, GNU Texinfo}, for more details on changing the
Info search path.)

@item
@cindex substitutes, authorization thereof
To use substitutes from @code{@value{SUBSTITUTE-SERVER}} or one of its mirrors
(@pxref{Substitutes}), authorize them:

@example
# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER}.pub
@end example

@item
Each user may need to perform a few additional steps to make their Guix
environment ready for use, @pxref{Application Setup}.
@end enumerate

Voilà, the installation is complete!

You can confirm that Guix is working by installing a sample package into
the root profile:

@example
# guix install hello
@end example

The binary installation tarball can be (re)produced and verified simply
by running the following command in the Guix source tree:

@example
make guix-binary.@var{system}.tar.xz
@end example

@noindent
...@: which, in turn, runs:

@example
guix pack -s @var{system} --localstatedir \
  --profile-name=current-guix guix
@end example

@xref{Invoking guix pack}, for more info on this handy tool.

@node Requirements
@section Requirements

This section lists requirements when building Guix from source.  The
build procedure for Guix is the same as for other GNU software, and is
not covered here.  Please see the files @file{README} and @file{INSTALL}
in the Guix source tree for additional details.

@cindex official website
GNU Guix is available for download from its website at
@url{https://www.gnu.org/software/guix/}.

GNU Guix depends on the following packages:

@itemize
@item @url{https://gnu.org/software/guile/, GNU Guile}, version 2.2.x;
@item @url{https://notabug.org/cwebber/guile-gcrypt, Guile-Gcrypt}, version
0.1.0 or later;
@item
@uref{https://gnutls.org/, GnuTLS}, specifically its Guile bindings
(@pxref{Guile Preparations, how to install the GnuTLS bindings for
Guile,, gnutls-guile, GnuTLS-Guile});
@item
@uref{https://notabug.org/guile-sqlite3/guile-sqlite3, Guile-SQLite3}, version 0.1.0
or later;
@item
@c FIXME: Specify a version number once a release has been made.
@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, from August
2017 or later;
@item @uref{https://savannah.nongnu.org/projects/guile-json/, Guile-JSON} 3.x;
@item @url{https://zlib.net, zlib};
@item @url{https://www.gnu.org/software/make/, GNU Make}.
@end itemize

The following dependencies are optional:

@itemize
@item
@c Note: We need at least 0.10.2 for 'channel-send-eof'.
Support for build offloading (@pxref{Daemon Offload Setup}) and
@command{guix copy} (@pxref{Invoking guix copy}) depends on
@uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH},
version 0.10.2 or later.

@item
When @url{https://www.nongnu.org/lzip/lzlib.html, lzlib} is available, lzlib
substitutes can be used and @command{guix publish} can compress substitutes
with lzlib.

@item
When @url{http://www.bzip.org, libbz2} is available,
@command{guix-daemon} can use it to compress build logs.
@end itemize

Unless @code{--disable-daemon} was passed to @command{configure}, the
following packages are also needed:

@itemize
@item @url{https://gnupg.org/, GNU libgcrypt};
@item @url{https://sqlite.org, SQLite 3};
@item @url{https://gcc.gnu.org, GCC's g++}, with support for the
C++11 standard.
@end itemize

@cindex state directory
When configuring Guix on a system that already has a Guix installation,
be sure to specify the same state directory as the existing installation
using the @code{--localstatedir} option of the @command{configure}
script (@pxref{Directory Variables, @code{localstatedir},, standards,
GNU Coding Standards}).  The @command{configure} script protects against
unintended misconfiguration of @var{localstatedir} so you do not
inadvertently corrupt your store (@pxref{The Store}).

@cindex Nix, compatibility
When a working installation of @url{https://nixos.org/nix/, the Nix package
manager} is available, you
can instead configure Guix with @code{--disable-daemon}.  In that case,
Nix replaces the three dependencies above.

Guix is compatible with Nix, so it is possible to share the same store
between both.  To do so, you must pass @command{configure} not only the
same @code{--with-store-dir} value, but also the same
@code{--localstatedir} value.  The latter is essential because it
specifies where the database that stores metadata about the store is
located, among other things.  The default values for Nix are
@code{--with-store-dir=/nix/store} and @code{--localstatedir=/nix/var}.
Note that @code{--disable-daemon} is not required if
your goal is to share the store with Nix.

@node Running the Test Suite
@section Running the Test Suite

@cindex test suite
After a successful @command{configure} and @code{make} run, it is a good
idea to run the test suite.  It can help catch issues with the setup or
environment, or bugs in Guix itself---and really, reporting test
failures is a good way to help improve the software.  To run the test
suite, type:

@example
make check
@end example

Test cases can run in parallel: you can use the @code{-j} option of
GNU@tie{}make to speed things up.  The first run may take a few minutes
on a recent machine; subsequent runs will be faster because the store
that is created for test purposes will already have various things in
cache.

It is also possible to run a subset of the tests by defining the
@code{TESTS} makefile variable as in this example:

@example
make check TESTS="tests/store.scm tests/cpio.scm"
@end example

By default, tests results are displayed at a file level.  In order to
see the details of every individual test cases, it is possible to define
the @code{SCM_LOG_DRIVER_FLAGS} makefile variable as in this example:

@example
make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"
@end example

Upon failure, please email @email{bug-guix@@gnu.org} and attach the
@file{test-suite.log} file.  Please specify the Guix version being used
as well as version numbers of the dependencies (@pxref{Requirements}) in
your message.

Guix also comes with a whole-system test suite that tests complete
Guix System instances.  It can only run on systems where
Guix is already installed, using:

@example
make check-system
@end example

@noindent
or, again, by defining @code{TESTS} to select a subset of tests to run:

@example
make check-system TESTS="basic mcron"
@end example

These system tests are defined in the @code{(gnu tests @dots{})}
modules.  They work by running the operating systems under test with
lightweight instrumentation in a virtual machine (VM).  They can be
computationally intensive or rather cheap, depending on whether
substitutes are available for their dependencies (@pxref{Substitutes}).
Some of them require a lot of storage space to hold VM images.

Again in case of test failures, please send @email{bug-guix@@gnu.org}
all the details.

@node Setting Up the Daemon
@section Setting Up the Daemon

@cindex daemon
Operations such as building a package or running the garbage collector
are all performed by a specialized process, the @dfn{build daemon}, on
behalf of clients.  Only the daemon may access the store and its
associated database.  Thus, any operation that manipulates the store
goes through the daemon.  For instance, command-line tools such as
@command{guix package} and @command{guix build} communicate with the
daemon (@i{via} remote procedure calls) to instruct it what to do.

The following sections explain how to prepare the build daemon's
environment.  See also @ref{Substitutes}, for information on how to allow
the daemon to download pre-built binaries.

@menu
* Build Environment Setup::     Preparing the isolated build environment.
* Daemon Offload Setup::        Offloading builds to remote machines.
* SELinux Support::             Using an SELinux policy for the daemon.
@end menu

@node Build Environment Setup
@subsection Build Environment Setup

@cindex build environment
In a standard multi-user setup, Guix and its daemon---the
@command{guix-daemon} program---are installed by the system
administrator; @file{/gnu/store} is owned by @code{root} and
@command{guix-daemon} runs as @code{root}.  Unprivileged users may use
Guix tools to build packages or otherwise access the store, and the
daemon will do it on their behalf, ensuring that the store is kept in a
consistent state, and allowing built packages to be shared among users.

@cindex build users
When @command{guix-daemon} runs as @code{root}, you may not want package
build processes themselves to run as @code{root} too, for obvious
security reasons.  To avoid that, a special pool of @dfn{build users}
should be created for use by build processes started by the daemon.
These build users need not have a shell and a home directory: they will
just be used when the daemon drops @code{root} privileges in build
processes.  Having several such users allows the daemon to launch
distinct build processes under separate UIDs, which guarantees that they
do not interfere with each other---an essential feature since builds are
regarded as pure functions (@pxref{Introduction}).

On a GNU/Linux system, a build user pool may be created like this (using
Bash syntax and the @code{shadow} commands):

@c See https://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html
@c for why `-G' is needed.
@example
# groupadd --system guixbuild
# for i in `seq -w 1 10`;
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s `which nologin`    \
            -c "Guix build user $i" --system    \
            guixbuilder$i;
  done
@end example

@noindent
The number of build users determines how many build jobs may run in
parallel, as specified by the @option{--max-jobs} option
(@pxref{Invoking guix-daemon, @option{--max-jobs}}).  To use
@command{guix system vm} and related commands, you may need to add the
build users to the @code{kvm} group so they can access @file{/dev/kvm},
using @code{-G guixbuild,kvm} instead of @code{-G guixbuild}
(@pxref{Invoking guix system}).

The @code{guix-daemon} program may then be run as @code{root} with the
following command@footnote{If your machine uses the systemd init system,
dropping the @file{@var{prefix}/lib/systemd/system/guix-daemon.service}
file in @file{/etc/systemd/system} will ensure that
@command{guix-daemon} is automatically started.  Similarly, if your
machine uses the Upstart init system, drop the
@file{@var{prefix}/lib/upstart/system/guix-daemon.conf}
file in @file{/etc/init}.}:

@example
# guix-daemon --build-users-group=guixbuild
@end example

@cindex chroot
@noindent
This way, the daemon starts build processes in a chroot, under one of
the @code{guixbuilder} users.  On GNU/Linux, by default, the chroot
environment contains nothing but:

@c Keep this list in sync with libstore/build.cc! -----------------------
@itemize
@item
a minimal @code{/dev} directory, created mostly independently from the
host @code{/dev}@footnote{``Mostly'', because while the set of files
that appear in the chroot's @code{/dev} is fixed, most of these files
can only be created if the host has them.};

@item
the @code{/proc} directory; it only shows the processes of the container
since a separate PID name space is used;

@item
@file{/etc/passwd} with an entry for the current user and an entry for
user @file{nobody};

@item
@file{/etc/group} with an entry for the user's group;

@item
@file{/etc/hosts} with an entry that maps @code{localhost} to
@code{127.0.0.1};

@item
a writable @file{/tmp} directory.
@end itemize

You can influence the directory where the daemon stores build trees
@i{via} the @code{TMPDIR} environment variable.  However, the build tree
within the chroot is always called @file{/tmp/guix-build-@var{name}.drv-0},
where @var{name} is the derivation name---e.g., @code{coreutils-8.24}.
This way, the value of @code{TMPDIR} does not leak inside build
environments, which avoids discrepancies in cases where build processes
capture the name of their build tree.

@vindex http_proxy
The daemon also honors the @code{http_proxy} environment variable for
HTTP downloads it performs, be it for fixed-output derivations
(@pxref{Derivations}) or for substitutes (@pxref{Substitutes}).

If you are installing Guix as an unprivileged user, it is still possible
to run @command{guix-daemon} provided you pass @code{--disable-chroot}.
However, build processes will not be isolated from one another, and not
from the rest of the system.  Thus, build processes may interfere with
each other, and may access programs, libraries, and other files
available on the system---making it much harder to view them as
@emph{pure} functions.


@node Daemon Offload Setup
@subsection Using the Offload Facility

@cindex offloading
@cindex build hook
When desired, the build daemon can @dfn{offload} derivation builds to
other machines running Guix, using the @code{offload} @dfn{build
hook}@footnote{This feature is available only when
@uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH} is
present.}.  When that
feature is enabled, a list of user-specified build machines is read from
@file{/etc/guix/machines.scm}; every time a build is requested, for
instance via @code{guix build}, the daemon attempts to offload it to one
of the machines that satisfy the constraints of the derivation, in
particular its system type---e.g., @file{x86_64-linux}.  Missing
prerequisites for the build are copied over SSH to the target machine,
which then proceeds with the build; upon success the output(s) of the
build are copied back to the initial machine.

The @file{/etc/guix/machines.scm} file typically looks like this:

@example
(list (build-machine
        (name "eightysix.example.org")
        (system "x86_64-linux")
        (host-key "ssh-ed25519 AAAAC3Nza@dots{}")
        (user "bob")
        (speed 2.))     ;incredibly fast!

      (build-machine
        (name "meeps.example.org")
        (system "mips64el-linux")
        (host-key "ssh-rsa AAAAB3Nza@dots{}")
        (user "alice")
        (private-key
         (string-append (getenv "HOME")
                        "/.ssh/identity-for-guix"))))
@end example

@noindent
In the example above we specify a list of two build machines, one for
the @code{x86_64} architecture and one for the @code{mips64el}
architecture.

In fact, this file is---not surprisingly!---a Scheme file that is
evaluated when the @code{offload} hook is started.  Its return value
must be a list of @code{build-machine} objects.  While this example
shows a fixed list of build machines, one could imagine, say, using
DNS-SD to return a list of potential build machines discovered in the
local network (@pxref{Introduction, Guile-Avahi,, guile-avahi, Using
Avahi in Guile Scheme Programs}).  The @code{build-machine} data type is
detailed below.

@deftp {Data Type} build-machine
This data type represents build machines to which the daemon may offload
builds.  The important fields are:

@table @code

@item name
The host name of the remote machine.

@item system
The system type of the remote machine---e.g., @code{"x86_64-linux"}.

@item user
The user account to use when connecting to the remote machine over SSH.
Note that the SSH key pair must @emph{not} be passphrase-protected, to
allow non-interactive logins.

@item host-key
This must be the machine's SSH @dfn{public host key} in OpenSSH format.
This is used to authenticate the machine when we connect to it.  It is a
long string that looks like this:

@example
ssh-ed25519 AAAAC3NzaC@dots{}mde+UhL hint@@example.org
@end example

If the machine is running the OpenSSH daemon, @command{sshd}, the host
key can be found in a file such as
@file{/etc/ssh/ssh_host_ed25519_key.pub}.

If the machine is running the SSH daemon of GNU@tie{}lsh,
@command{lshd}, the host key is in @file{/etc/lsh/host-key.pub} or a
similar file.  It can be converted to the OpenSSH format using
@command{lsh-export-key} (@pxref{Converting keys,,, lsh, LSH Manual}):

@example
$ lsh-export-key --openssh < /etc/lsh/host-key.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV@dots{}
@end example

@end table

A number of optional fields may be specified:

@table @asis

@item @code{port} (default: @code{22})
Port number of SSH server on the machine.

@item @code{private-key} (default: @file{~root/.ssh/id_rsa})
The SSH private key file to use when connecting to the machine, in
OpenSSH format.  This key must not be protected with a passphrase.

Note that the default value is the private key @emph{of the root
account}.  Make sure it exists if you use the default.

@item @code{compression} (default: @code{"zlib@@openssh.com,zlib"})
@itemx @code{compression-level} (default: @code{3})
The SSH-level compression methods and compression level requested.

Note that offloading relies on SSH compression to reduce bandwidth usage
when transferring files to and from build machines.

@item @code{daemon-socket} (default: @code{"/var/guix/daemon-socket/socket"})
File name of the Unix-domain socket @command{guix-daemon} is listening
to on that machine.

@item @code{parallel-builds} (default: @code{1})
The number of builds that may run in parallel on the machine.

@item @code{speed} (default: @code{1.0})
A ``relative speed factor''.  The offload scheduler will tend to prefer
machines with a higher speed factor.

@item @code{features} (default: @code{'()})
A list of strings denoting specific features supported by the machine.
An example is @code{"kvm"} for machines that have the KVM Linux modules
and corresponding hardware support.  Derivations can request features by
name, and they will be scheduled on matching build machines.

@end table
@end deftp

The @command{guix} command must be in the search path on the build
machines.  You can check whether this is the case by running:

@example
ssh build-machine guix repl --version
@end example

There is one last thing to do once @file{machines.scm} is in place.  As
explained above, when offloading, files are transferred back and forth
between the machine stores.  For this to work, you first need to
generate a key pair on each machine to allow the daemon to export signed
archives of files from the store (@pxref{Invoking guix archive}):

@example
# guix archive --generate-key
@end example

@noindent
Each build machine must authorize the key of the master machine so that
it accepts store items it receives from the master:

@example
# guix archive --authorize < master-public-key.txt
@end example

@noindent
Likewise, the master machine must authorize the key of each build machine.

All the fuss with keys is here to express pairwise mutual trust
relations between the master and the build machines.  Concretely, when
the master receives files from a build machine (and @i{vice versa}), its
build daemon can make sure they are genuine, have not been tampered
with, and that they are signed by an authorized key.

@cindex offload test
To test whether your setup is operational, run this command on the
master node:

@example
# guix offload test
@end example

This will attempt to connect to each of the build machines specified in
@file{/etc/guix/machines.scm}, make sure Guile and the Guix modules are
available on each machine, attempt to export to the machine and import
from it, and report any error in the process.

If you want to test a different machine file, just specify it on the
command line:

@example
# guix offload test machines-qualif.scm
@end example

Last, you can test the subset of the machines whose name matches a
regular expression like this:

@example
# guix offload test machines.scm '\.gnu\.org$'
@end example

@cindex offload status
To display the current load of all build hosts, run this command on the
main node:

@example
# guix offload status
@end example


@node SELinux Support
@subsection SELinux Support

@cindex SELinux, daemon policy
@cindex mandatory access control, SELinux
@cindex security, guix-daemon
Guix includes an SELinux policy file at @file{etc/guix-daemon.cil} that
can be installed on a system where SELinux is enabled, in order to label
Guix files and to specify the expected behavior of the daemon.  Since
Guix System does not provide an SELinux base policy, the daemon policy cannot
be used on Guix System.

@subsubsection Installing the SELinux policy
@cindex SELinux, policy installation
To install the policy run this command as root:

@example
semodule -i etc/guix-daemon.cil
@end example

Then relabel the file system with @code{restorecon} or by a different
mechanism provided by your system.

Once the policy is installed, the file system has been relabeled, and
the daemon has been restarted, it should be running in the
@code{guix_daemon_t} context.  You can confirm this with the following
command:

@example
ps -Zax | grep guix-daemon
@end example

Monitor the SELinux log files as you run a command like @code{guix build
hello} to convince yourself that SELinux permits all necessary
operations.

@subsubsection Limitations
@cindex SELinux, limitations

This policy is not perfect.  Here is a list of limitations or quirks
that should be considered when deploying the provided SELinux policy for
the Guix daemon.

@enumerate
@item
@code{guix_daemon_socket_t} isn’t actually used.  None of the socket
operations involve contexts that have anything to do with
@code{guix_daemon_socket_t}.  It doesn’t hurt to have this unused label,
but it would be preferrable to define socket rules for only this label.

@item
@code{guix gc} cannot access arbitrary links to profiles.  By design,
the file label of the destination of a symlink is independent of the
file label of the link itself.  Although all profiles under
$localstatedir are labelled, the links to these profiles inherit the
label of the directory they are in.  For links in the user’s home
directory this will be @code{user_home_t}.  But for links from the root
user’s home directory, or @file{/tmp}, or the HTTP server’s working
directory, etc, this won’t work.  @code{guix gc} would be prevented from
reading and following these links.

@item
The daemon’s feature to listen for TCP connections might no longer work.
This might require extra rules, because SELinux treats network sockets
differently from files.

@item
Currently all files with a name matching the regular expression
@code{/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon} are assigned the
label @code{guix_daemon_exec_t}; this means that @emph{any} file with
that name in any profile would be permitted to run in the
@code{guix_daemon_t} domain.  This is not ideal.  An attacker could
build a package that provides this executable and convince a user to
install and run it, which lifts it into the @code{guix_daemon_t} domain.
At that point SELinux could not prevent it from accessing files that are
allowed for processes in that domain.

We could generate a much more restrictive policy at installation time,
so that only the @emph{exact} file name of the currently installed
@code{guix-daemon} executable would be labelled with
@code{guix_daemon_exec_t}, instead of using a broad regular expression.
The downside is that root would have to install or upgrade the policy at
installation time whenever the Guix package that provides the
effectively running @code{guix-daemon} executable is upgraded.
@end enumerate

@node Invoking guix-daemon
@section Invoking @command{guix-daemon}

The @command{guix-daemon} program implements all the functionality to
access the store.  This includes launching build processes, running the
garbage collector, querying the availability of a build result, etc.  It
is normally run as @code{root} like this:

@example
# guix-daemon --build-users-group=guixbuild
@end example

@noindent
For details on how to set it up, @pxref{Setting Up the Daemon}.

@cindex chroot
@cindex container, build environment
@cindex build environment
@cindex reproducible builds
By default, @command{guix-daemon} launches build processes under
different UIDs, taken from the build group specified with
@code{--build-users-group}.  In addition, each build process is run in a
chroot environment that only contains the subset of the store that the
build process depends on, as specified by its derivation
(@pxref{Programming Interface, derivation}), plus a set of specific
system directories.  By default, the latter contains @file{/dev} and
@file{/dev/pts}.  Furthermore, on GNU/Linux, the build environment is a
@dfn{container}: in addition to having its own file system tree, it has
a separate mount name space, its own PID name space, network name space,
etc.  This helps achieve reproducible builds (@pxref{Features}).

When the daemon performs a build on behalf of the user, it creates a
build directory under @file{/tmp} or under the directory specified by
its @code{TMPDIR} environment variable.  This directory is shared with
the container for the duration of the build, though within the container,
the build tree is always called @file{/tmp/guix-build-@var{name}.drv-0}.

The build directory is automatically deleted upon completion, unless the
build failed and the client specified @option{--keep-failed}
(@pxref{Invoking guix build, @option{--keep-failed}}).

The daemon listens for connections and spawns one sub-process for each session
started by a client (one of the @command{guix} sub-commands.)  The
@command{guix processes} command allows you to get an overview of the activity
on your system by viewing each of the active sessions and clients.
@xref{Invoking guix processes}, for more information.

The following command-line options are supported:

@table @code
@item --build-users-group=@var{group}
Take users from @var{group} to run build processes (@pxref{Setting Up
the Daemon, build users}).

@item --no-substitutes
@cindex substitutes
Do not use substitutes for build products.  That is, always build things
locally instead of allowing downloads of pre-built binaries
(@pxref{Substitutes}).

When the daemon runs with @code{--no-substitutes}, clients can still
explicitly enable substitution @i{via} the @code{set-build-options}
remote procedure call (@pxref{The Store}).

@item --substitute-urls=@var{urls}
@anchor{daemon-substitute-urls}
Consider @var{urls} the default whitespace-separated list of substitute
source URLs.  When this option is omitted,
@indicateurl{https://@value{SUBSTITUTE-SERVER}} is used.

This means that substitutes may be downloaded from @var{urls}, as long
as they are signed by a trusted signature (@pxref{Substitutes}).

@cindex build hook
@item --no-build-hook
Do not use the @dfn{build hook}.

The build hook is a helper program that the daemon can start and to
which it submits build requests.  This mechanism is used to offload
builds to other machines (@pxref{Daemon Offload Setup}).

@item --cache-failures
Cache build failures.  By default, only successful builds are cached.

When this option is used, @command{guix gc --list-failures} can be used
to query the set of store items marked as failed; @command{guix gc
--clear-failures} removes store items from the set of cached failures.
@xref{Invoking guix gc}.

@item --cores=@var{n}
@itemx -c @var{n}
Use @var{n} CPU cores to build each derivation; @code{0} means as many
as available.

The default value is @code{0}, but it may be overridden by clients, such
as the @code{--cores} option of @command{guix build} (@pxref{Invoking
guix build}).

The effect is to define the @code{NIX_BUILD_CORES} environment variable
in the build process, which can then use it to exploit internal
parallelism---for instance, by running @code{make -j$NIX_BUILD_CORES}.

@item --max-jobs=@var{n}
@itemx -M @var{n}
Allow at most @var{n} build jobs in parallel.  The default value is
@code{1}.  Setting it to @code{0} means that no builds will be performed
locally; instead, the daemon will offload builds (@pxref{Daemon Offload
Setup}), or simply fail.

@item --max-silent-time=@var{seconds}
When the build or substitution process remains silent for more than
@var{seconds}, terminate it and report a build failure.

The default value is @code{0}, which disables the timeout.

The value specified here can be overridden by clients (@pxref{Common
Build Options, @code{--max-silent-time}}).

@item --timeout=@var{seconds}
Likewise, when the build or substitution process lasts for more than
@var{seconds}, terminate it and report a build failure.

The default value is @code{0}, which disables the timeout.

The value specified here can be overridden by clients (@pxref{Common
Build Options, @code{--timeout}}).

@item --rounds=@var{N}
Build each derivation @var{n} times in a row, and raise an error if
consecutive build results are not bit-for-bit identical.  Note that this
setting can be overridden by clients such as @command{guix build}
(@pxref{Invoking guix build}).

When used in conjunction with @option{--keep-failed}, the differing
output is kept in the store, under @file{/gnu/store/@dots{}-check}.
This makes it easy to look for differences between the two results.

@item --debug
Produce debugging output.

This is useful to debug daemon start-up issues, but then it may be
overridden by clients, for example the @code{--verbosity} option of
@command{guix build} (@pxref{Invoking guix build}).

@item --chroot-directory=@var{dir}
Add @var{dir} to the build chroot.

Doing this may change the result of build processes---for instance if
they use optional dependencies found in @var{dir} when it is available,
and not otherwise.  For that reason, it is not recommended to do so.
Instead, make sure that each derivation declares all the inputs that it
needs.

@item --disable-chroot
Disable chroot builds.

Using this option is not recommended since, again, it would allow build
processes to gain access to undeclared dependencies.  It is necessary,
though, when @command{guix-daemon} is running under an unprivileged user
account.

@item --log-compression=@var{type}
Compress build logs according to @var{type}, one of @code{gzip},
@code{bzip2}, or @code{none}.

Unless @code{--lose-logs} is used, all the build logs are kept in the
@var{localstatedir}.  To save space, the daemon automatically compresses
them with bzip2 by default.

@item --disable-deduplication
@cindex deduplication
Disable automatic file ``deduplication'' in the store.

By default, files added to the store are automatically ``deduplicated'':
if a newly added file is identical to another one found in the store,
the daemon makes the new file a hard link to the other file.  This can
noticeably reduce disk usage, at the expense of slightly increased
input/output load at the end of a build process.  This option disables
this optimization.

@item --gc-keep-outputs[=yes|no]
Tell whether the garbage collector (GC) must keep outputs of live
derivations.

@cindex GC roots
@cindex garbage collector roots
When set to ``yes'', the GC will keep the outputs of any live derivation
available in the store---the @code{.drv} files.  The default is ``no'',
meaning that derivation outputs are kept only if they are reachable from a GC
root.  @xref{Invoking guix gc}, for more on GC roots.

@item --gc-keep-derivations[=yes|no]
Tell whether the garbage collector (GC) must keep derivations
corresponding to live outputs.

When set to ``yes'', as is the case by default, the GC keeps
derivations---i.e., @code{.drv} files---as long as at least one of their
outputs is live.  This allows users to keep track of the origins of
items in their store.  Setting it to ``no'' saves a bit of disk space.

In this way, setting @code{--gc-keep-derivations} to ``yes'' causes liveness
to flow from outputs to derivations, and setting @code{--gc-keep-outputs} to
``yes'' causes liveness to flow from derivations to outputs.  When both are
set to ``yes'', the effect is to keep all the build prerequisites (the
sources, compiler, libraries, and other build-time tools) of live objects in
the store, regardless of whether these prerequisites are reachable from a GC
root.  This is convenient for developers since it saves rebuilds or downloads.

@item --impersonate-linux-2.6
On Linux-based systems, impersonate Linux 2.6.  This means that the
kernel's @code{uname} system call will report 2.6 as the release number.

This might be helpful to build programs that (usually wrongfully) depend
on the kernel version number.

@item --lose-logs
Do not keep build logs.  By default they are kept under
@code{@var{localstatedir}/guix/log}.

@item --system=@var{system}
Assume @var{system} as the current system type.  By default it is the
architecture/kernel pair found at configure time, such as
@code{x86_64-linux}.

@item --listen=@var{endpoint}
Listen for connections on @var{endpoint}.  @var{endpoint} is interpreted
as the file name of a Unix-domain socket if it starts with
@code{/} (slash sign).  Otherwise, @var{endpoint} is interpreted as a
host name or host name and port to listen to.  Here are a few examples:

@table @code
@item --listen=/gnu/var/daemon
Listen for connections on the @file{/gnu/var/daemon} Unix-domain socket,
creating it if needed.

@item --listen=localhost
@cindex daemon, remote access
@cindex remote access to the daemon
@cindex daemon, cluster setup
@cindex clusters, daemon setup
Listen for TCP connections on the network interface corresponding to
@code{localhost}, on port 44146.

@item --listen=128.0.0.42:1234
Listen for TCP connections on the network interface corresponding to
@code{128.0.0.42}, on port 1234.
@end table

This option can be repeated multiple times, in which case
@command{guix-daemon} accepts connections on all the specified
endpoints.  Users can tell client commands what endpoint to connect to
by setting the @code{GUIX_DAEMON_SOCKET} environment variable
(@pxref{The Store, @code{GUIX_DAEMON_SOCKET}}).

@quotation Note
The daemon protocol is @emph{unauthenticated and unencrypted}.  Using
@code{--listen=@var{host}} is suitable on local networks, such as
clusters, where only trusted nodes may connect to the build daemon.  In
other cases where remote access to the daemon is needed, we recommend
using Unix-domain sockets along with SSH.
@end quotation

When @code{--listen} is omitted, @command{guix-daemon} listens for
connections on the Unix-domain socket located at
@file{@var{localstatedir}/guix/daemon-socket/socket}.
@end table


@node Application Setup
@section Application Setup

@cindex foreign distro
When using Guix on top of GNU/Linux distribution other than Guix System---a
so-called @dfn{foreign distro}---a few additional steps are needed to
get everything in place.  Here are some of them.

@subsection Locales

@anchor{locales-and-locpath}
@cindex locales, when not on Guix System
@vindex LOCPATH
@vindex GUIX_LOCPATH
Packages installed @i{via} Guix will not use the locale data of the
host system.  Instead, you must first install one of the locale packages
available with Guix and then define the @code{GUIX_LOCPATH} environment
variable:

@example
$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
@end example

Note that the @code{glibc-locales} package contains data for all the
locales supported by the GNU@tie{}libc and weighs in at around
110@tie{}MiB.  Alternatively, the @code{glibc-utf8-locales} is smaller but
limited to a few UTF-8 locales.

The @code{GUIX_LOCPATH} variable plays a role similar to @code{LOCPATH}
(@pxref{Locale Names, @code{LOCPATH},, libc, The GNU C Library Reference
Manual}).  There are two important differences though:

@enumerate
@item
@code{GUIX_LOCPATH} is honored only by the libc in Guix, and not by the libc
provided by foreign distros.  Thus, using @code{GUIX_LOCPATH} allows you
to make sure the programs of the foreign distro will not end up loading
incompatible locale data.

@item
libc suffixes each entry of @code{GUIX_LOCPATH} with @code{/X.Y}, where
@code{X.Y} is the libc version---e.g., @code{2.22}.  This means that,
should your Guix profile contain a mixture of programs linked against
different libc version, each libc version will only try to load locale
data in the right format.
@end enumerate

This is important because the locale data format used by different libc
versions may be incompatible.

@subsection Name Service Switch

@cindex name service switch, glibc
@cindex NSS (name service switch), glibc
@cindex nscd (name service caching daemon)
@cindex name service caching daemon (nscd)
When using Guix on a foreign distro, we @emph{strongly recommend} that
the system run the GNU C library's @dfn{name service cache daemon},
@command{nscd}, which should be listening on the
@file{/var/run/nscd/socket} socket.  Failing to do that, applications
installed with Guix may fail to look up host names or user accounts, or
may even crash.  The next paragraphs explain why.

@cindex @file{nsswitch.conf}
The GNU C library implements a @dfn{name service switch} (NSS), which is
an extensible mechanism for ``name lookups'' in general: host name
resolution, user accounts, and more (@pxref{Name Service Switch,,, libc,
The GNU C Library Reference Manual}).

@cindex Network information service (NIS)
@cindex NIS (Network information service)
Being extensible, the NSS supports @dfn{plugins}, which provide new name
lookup implementations: for example, the @code{nss-mdns} plugin allow
resolution of @code{.local} host names, the @code{nis} plugin allows
user account lookup using the Network information service (NIS), and so
on.  These extra ``lookup services'' are configured system-wide in
@file{/etc/nsswitch.conf}, and all the programs running on the system
honor those settings (@pxref{NSS Configuration File,,, libc, The GNU C
Reference Manual}).

When they perform a name lookup---for instance by calling the
@code{getaddrinfo} function in C---applications first try to connect to
the nscd; on success, nscd performs name lookups on their behalf.  If
the nscd is not running, then they perform the name lookup by
themselves, by loading the name lookup services into their own address
space and running it.  These name lookup services---the
@file{libnss_*.so} files---are @code{dlopen}'d, but they may come from
the host system's C library, rather than from the C library the
application is linked against (the C library coming from Guix).

And this is where the problem is: if your application is linked against
Guix's C library (say, glibc 2.24) and tries to load NSS plugins from
another C library (say, @code{libnss_mdns.so} for glibc 2.22), it will
likely crash or have its name lookups fail unexpectedly.

Running @command{nscd} on the system, among other advantages, eliminates
this binary incompatibility problem because those @code{libnss_*.so}
files are loaded in the @command{nscd} process, not in applications
themselves.

@subsection X11 Fonts

@cindex fonts
The majority of graphical applications use Fontconfig to locate and
load fonts and perform X11-client-side rendering.  The @code{fontconfig}
package in Guix looks for fonts in @file{$HOME/.guix-profile}
by default.  Thus, to allow graphical applications installed with Guix
to display fonts, you have to install fonts with Guix as well.
Essential font packages include @code{gs-fonts}, @code{font-dejavu}, and
@code{font-gnu-freefont-ttf}.

To display text written in Chinese languages, Japanese, or Korean in
graphical applications, consider installing
@code{font-adobe-source-han-sans} or @code{font-wqy-zenhei}.  The former
has multiple outputs, one per language family (@pxref{Packages with
Multiple Outputs}).  For instance, the following command installs fonts
for Chinese languages:

@example
guix install font-adobe-source-han-sans:cn
@end example

@cindex @code{xterm}
Older programs such as @command{xterm} do not use Fontconfig and instead
rely on server-side font rendering.  Such programs require to specify a
full name of a font using XLFD (X Logical Font Description), like this:

@example
-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1
@end example

To be able to use such full names for the TrueType fonts installed in
your Guix profile, you need to extend the font path of the X server:

@c Note: 'xset' does not accept symlinks so the trick below arranges to
@c get at the real directory.  See <https://bugs.gnu.org/30655>.
@example
xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))
@end example

@cindex @code{xlsfonts}
After that, you can run @code{xlsfonts} (from @code{xlsfonts} package)
to make sure your TrueType fonts are listed there.

@cindex @code{fc-cache}
@cindex font cache
After installing fonts you may have to refresh the font cache to use
them in applications.  The same applies when applications installed via
Guix do not seem to find fonts.  To force rebuilding of the font cache
run @code{fc-cache -f}.  The @code{fc-cache} command is provided by the
@code{fontconfig} package.

@subsection X.509 Certificates

@cindex @code{nss-certs}
The @code{nss-certs} package provides X.509 certificates, which allow
programs to authenticate Web servers accessed over HTTPS.

When using Guix on a foreign distro, you can install this package and
define the relevant environment variables so that packages know where to
look for certificates.  @xref{X.509 Certificates}, for detailed
information.

@subsection Emacs Packages

@cindex @code{emacs}
When you install Emacs packages with Guix, the elisp files may be placed
either in @file{$HOME/.guix-profile/share/emacs/site-lisp/} or in
sub-directories of
@file{$HOME/.guix-profile/share/emacs/site-lisp/guix.d/}.  The latter
directory exists because potentially there may exist thousands of Emacs
packages and storing all their files in a single directory may not be
reliable (because of name conflicts).  So we think using a separate
directory for each package is a good idea.  It is very similar to how
the Emacs package system organizes the file structure (@pxref{Package
Files,,, emacs, The GNU Emacs Manual}).

By default, Emacs (installed with Guix) ``knows'' where these packages
are placed, so you do not need to perform any configuration.  If, for
some reason, you want to avoid auto-loading Emacs packages installed
with Guix, you can do so by running Emacs with @code{--no-site-file}
option (@pxref{Init File,,, emacs, The GNU Emacs Manual}).

@subsection The GCC toolchain

@cindex GCC
@cindex ld-wrapper

Guix offers individual compiler packages such as @code{gcc} but if you
are in need of a complete toolchain for compiling and linking source
code what you really want is the @code{gcc-toolchain} package.  This
package provides a complete GCC toolchain for C/C++ development,
including GCC itself, the GNU C Library (headers and binaries, plus
debugging symbols in the @code{debug} output), Binutils, and a linker
wrapper.

The wrapper's purpose is to inspect the @code{-L} and @code{-l} switches
passed to the linker, add corresponding @code{-rpath} arguments, and
invoke the actual linker with this new set of arguments.  You can instruct the
wrapper to refuse to link against libraries not in the store by setting the
@code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.

@c TODO What else?

@c *********************************************************************
@node System Installation
@chapter System Installation

@cindex installing Guix System
@cindex Guix System, installation
This section explains how to install Guix System
on a machine.  Guix, as a package manager, can
also be installed on top of a running GNU/Linux system,
@pxref{Installation}.

@ifinfo
@quotation Note
@c This paragraph is for people reading this from tty2 of the
@c installation image.
You are reading this documentation with an Info reader.  For details on
how to use it, hit the @key{RET} key (``return'' or ``enter'') on the
link that follows: @pxref{Top, Info reader,, info-stnd, Stand-alone GNU
Info}.  Hit @kbd{l} afterwards to come back here.

Alternately, run @command{info info} in another tty to keep the manual
available.
@end quotation
@end ifinfo

@menu
* Limitations::                 What you can expect.
* Hardware Considerations::     Supported hardware.
* USB Stick and DVD Installation::  Preparing the installation medium.
* Preparing for Installation::  Networking, partitioning, etc.
* Guided Graphical Installation::  Easy graphical installation.
* Manual Installation::         Manual installation for wizards.
* After System Installation::   When installation succeeded.
* Installing Guix in a VM::     Guix System playground.
* Building the Installation Image::  How this comes to be.
@end menu

@node Limitations
@section Limitations

We consider Guix System to be ready for a wide range of ``desktop'' and server
use cases.  The reliability guarantees it provides---transactional upgrades
and rollbacks, reproducibility---make it a solid foundation.

Nevertheless, before you proceed with the installation, be aware of the
following noteworthy limitations applicable to version @value{VERSION}:

@itemize
@item
Support for the Logical Volume Manager (LVM) is missing.

@item
More and more system services are provided (@pxref{Services}), but some
may be missing.

@item
GNOME, Xfce, LXDE, and Enlightenment are available (@pxref{Desktop Services}),
as well as a number of X11 window managers.  However, KDE is currently
missing.
@end itemize

More than a disclaimer, this is an invitation to report issues (and success
stories!), and to join us in improving it.  @xref{Contributing}, for more
info.


@node Hardware Considerations
@section Hardware Considerations

@cindex hardware support on Guix System
GNU@tie{}Guix focuses on respecting the user's computing freedom.  It
builds around the kernel Linux-libre, which means that only hardware for
which free software drivers and firmware exist is supported.  Nowadays,
a wide range of off-the-shelf hardware is supported on
GNU/Linux-libre---from keyboards to graphics cards to scanners and
Ethernet controllers.  Unfortunately, there are still areas where
hardware vendors deny users control over their own computing, and such
hardware is not supported on Guix System.

@cindex WiFi, hardware support
One of the main areas where free drivers or firmware are lacking is WiFi
devices.  WiFi devices known to work include those using Atheros chips
(AR9271 and AR7010), which corresponds to the @code{ath9k} Linux-libre
driver, and those using Broadcom/AirForce chips (BCM43xx with
Wireless-Core Revision 5), which corresponds to the @code{b43-open}
Linux-libre driver.  Free firmware exists for both and is available
out-of-the-box on Guix System, as part of @code{%base-firmware}
(@pxref{operating-system Reference, @code{firmware}}).

@cindex RYF, Respects Your Freedom
The @uref{https://www.fsf.org/, Free Software Foundation} runs
@uref{https://www.fsf.org/ryf, @dfn{Respects Your Freedom}} (RYF), a
certification program for hardware products that respect your freedom
and your privacy and ensure that you have control over your device.  We
encourage you to check the list of RYF-certified devices.

Another useful resource is the @uref{https://www.h-node.org/, H-Node}
web site.  It contains a catalog of hardware devices with information
about their support in GNU/Linux.


@node USB Stick and DVD Installation
@section USB Stick and DVD Installation

An ISO-9660 installation image that can be written to a USB stick or
burnt to a DVD can be downloaded from
@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.@var{system}.iso.xz},
where @var{system} is one of:

@table @code
@item x86_64-linux
for a GNU/Linux system on Intel/AMD-compatible 64-bit CPUs;

@item i686-linux
for a 32-bit GNU/Linux system on Intel-compatible CPUs.
@end table

@c start duplication of authentication part from ``Binary Installation''
Make sure to download the associated @file{.sig} file and to verify the
authenticity of the image against it, along these lines:

@example
$ wget @value{BASE-URL}/guix-system-install-@value{VERSION}.@var{system}.iso.xz.sig
$ gpg --verify guix-system-install-@value{VERSION}.@var{system}.iso.xz.sig
@end example

If that command fails because you do not have the required public key,
then run this command to import it:

@example
$ wget @value{OPENPGP-SIGNING-KEY-URL} \
      -qO - | gpg --import -
@end example

@noindent
and rerun the @code{gpg --verify} command.

Take note that a warning like ``This key is not certified with a trusted
signature!'' is normal.

@c end duplication

This image contains the tools necessary for an installation.
It is meant to be copied @emph{as is} to a large-enough USB stick or DVD.

@unnumberedsubsec Copying to a USB Stick

To copy the image to a USB stick, follow these steps:

@enumerate
@item
Decompress the image using the @command{xz} command:

@example
xz -d guix-system-install-@value{VERSION}.@var{system}.iso.xz
@end example

@item
Insert a USB stick of 1@tie{}GiB or more into your machine, and determine
its device name.  Assuming that the USB stick is known as @file{/dev/sdX},
copy the image with:

@example
dd if=guix-system-install-@value{VERSION}.@var{system}.iso of=/dev/sdX
sync
@end example

Access to @file{/dev/sdX} usually requires root privileges.
@end enumerate

@unnumberedsubsec Burning on a DVD

To copy the image to a DVD, follow these steps:

@enumerate
@item
Decompress the image using the @command{xz} command:

@example
xz -d guix-system-install-@value{VERSION}.@var{system}.iso.xz
@end example

@item
Insert a blank DVD into your machine, and determine
its device name.  Assuming that the DVD drive is known as @file{/dev/srX},
copy the image with:

@example
growisofs -dvd-compat -Z /dev/srX=guix-system-install-@value{VERSION}.@var{system}.iso
@end example

Access to @file{/dev/srX} usually requires root privileges.
@end enumerate

@unnumberedsubsec Booting

Once this is done, you should be able to reboot the system and boot from
the USB stick or DVD.  The latter usually requires you to get in the
BIOS or UEFI boot menu, where you can choose to boot from the USB stick.

@xref{Installing Guix in a VM}, if, instead, you would like to install
Guix System in a virtual machine (VM).


@node Preparing for Installation
@section Preparing for Installation

Once you have booted, you can use the guided graphical installer, which makes
it easy to get started (@pxref{Guided Graphical Installation}).  Alternately,
if you are already familiar with GNU/Linux and if you want more control than
what the graphical installer provides, you can choose the ``manual''
installation process (@pxref{Manual Installation}).

The graphical installer is available on TTY1.  You can obtain root shells on
TTYs 3 to 6 by hitting @kbd{ctrl-alt-f3}, @kbd{ctrl-alt-f4}, etc.  TTY2 shows
this documentation and you can reach it with @kbd{ctrl-alt-f2}.  Documentation
is browsable using the Info reader commands (@pxref{Top,,, info-stnd,
Stand-alone GNU Info}).  The installation system runs the GPM mouse daemon,
which allows you to select text with the left mouse button and to paste it
with the middle button.

@quotation Note
Installation requires access to the Internet so that any missing
dependencies of your system configuration can be downloaded.  See the
``Networking'' section below.
@end quotation

@node Guided Graphical Installation
@section Guided Graphical Installation

The graphical installer is a text-based user interface.  It will guide you,
with dialog boxes, through the steps needed to install GNU@tie{}Guix System.

The first dialog boxes allow you to set up the system as you use it during the
installation: you can choose the language, keyboard layout, and set up
networking, which will be used during the installation.  The image below shows
the networking dialog.

@image{images/installer-network,5in,, networking setup with the graphical installer}

Later steps allow you to partition your hard disk, as shown in the image
below, to choose whether or not to use encrypted file systems, to enter the
host name and root password, and to create an additional account, among other
things.

@image{images/installer-partitions,5in,, partitioning with the graphical installer}

Note that, at any time, the installer allows you to exit the current
installation step and resume at a previous step, as show in the image below.

@image{images/installer-resume,5in,, resuming the installation process}

Once you're done, the installer produces an operating system configuration and
displays it (@pxref{Using the Configuration System}).  At that point you can
hit ``OK'' and installation will proceed.  On success, you can reboot into the
new system and enjoy.  @xref{After System Installation}, for what's next!


@node Manual Installation
@section Manual Installation

This section describes how you would ``manually'' install GNU@tie{}Guix System
on your machine.  This option requires familiarity with GNU/Linux, with the
shell, and with common administration tools.  If you think this is not for
you, consider using the guided graphical installer (@pxref{Guided Graphical
Installation}).

The installation system provides root shells on TTYs 3 to 6; press
@kbd{ctrl-alt-f3}, @kbd{ctrl-alt-f4}, and so on to reach them.  It includes
many common tools needed to install the system.  But it is also a full-blown
Guix System, which means that you can install additional packages, should you
need it, using @command{guix package} (@pxref{Invoking guix package}).

@menu
* Keyboard Layout and Networking and Partitioning:: Initial setup.
* Proceeding with the Installation::  Installing.
@end menu

@node Keyboard Layout and Networking and Partitioning
@subsection Keyboard Layout, Networking, and Partitioning

Before you can install the system, you may want to adjust the keyboard layout,
set up networking, and partition your target hard disk.  This section will
guide you through this.

@subsubsection Keyboard Layout

@cindex keyboard layout
The installation image uses the US qwerty keyboard layout.  If you want
to change it, you can use the @command{loadkeys} command.  For example,
the following command selects the Dvorak keyboard layout:

@example
loadkeys dvorak
@end example

See the files under @file{/run/current-system/profile/share/keymaps} for
a list of available keyboard layouts.  Run @command{man loadkeys} for
more information.

@subsubsection Networking

Run the following command to see what your network interfaces are called:

@example
ifconfig -a
@end example

@noindent
@dots{} or, using the GNU/Linux-specific @command{ip} command:

@example
ip a
@end example

@c https://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
Wired interfaces have a name starting with @samp{e}; for example, the
interface corresponding to the first on-board Ethernet controller is
called @samp{eno1}.  Wireless interfaces have a name starting with
@samp{w}, like @samp{w1p2s0}.

@table @asis
@item Wired connection
To configure a wired network run the following command, substituting
@var{interface} with the name of the wired interface you want to use.

@example
ifconfig @var{interface} up
@end example

@item Wireless connection
@cindex wireless
@cindex WiFi
To configure wireless networking, you can create a configuration file
for the @command{wpa_supplicant} configuration tool (its location is not
important) using one of the available text editors such as
@command{nano}:

@example
nano wpa_supplicant.conf
@end example

As an example, the following stanza can go to this file and will work
for many wireless networks, provided you give the actual SSID and
passphrase for the network you are connecting to:

@example
network=@{
  ssid="@var{my-ssid}"
  key_mgmt=WPA-PSK
  psk="the network's secret passphrase"
@}
@end example

Start the wireless service and run it in the background with the
following command (substitute @var{interface} with the name of the
network interface you want to use):

@example
wpa_supplicant -c wpa_supplicant.conf -i @var{interface} -B
@end example

Run @command{man wpa_supplicant} for more information.
@end table

@cindex DHCP
At this point, you need to acquire an IP address.  On a network where IP
addresses are automatically assigned @i{via} DHCP, you can run:

@example
dhclient -v @var{interface}
@end example

Try to ping a server to see if networking is up and running:

@example
ping -c 3 gnu.org
@end example

Setting up network access is almost always a requirement because the
image does not contain all the software and tools that may be needed.

@cindex installing over SSH
If you want to, you can continue the installation remotely by starting
an SSH server:

@example
herd start ssh-daemon
@end example

Make sure to either set a password with @command{passwd}, or configure
OpenSSH public key authentication before logging in.

@subsubsection Disk Partitioning

Unless this has already been done, the next step is to partition, and
then format the target partition(s).

The installation image includes several partitioning tools, including
Parted (@pxref{Overview,,, parted, GNU Parted User Manual}),
@command{fdisk}, and @command{cfdisk}.  Run it and set up your disk with
the partition layout you want:

@example
cfdisk
@end example

If your disk uses the GUID Partition Table (GPT) format and you plan to
install BIOS-based GRUB (which is the default), make sure a BIOS Boot
Partition is available (@pxref{BIOS installation,,, grub, GNU GRUB
manual}).

@cindex EFI, installation
@cindex UEFI, installation
@cindex ESP, EFI system partition
If you instead wish to use EFI-based GRUB, a FAT32 @dfn{EFI System Partition}
(ESP) is required.  This partition can be mounted at @file{/boot/efi} for
instance and must have the @code{esp} flag set.  E.g., for @command{parted}: