Once you have written an operating system declaration as seen in the
previous section, it can be instantiated using the
system command. The synopsis is:
guix system options… action file
file must be the name of a file containing an
operating-system declaration. action specifies how the
operating system is instantiated. Currently the following values are
Display available service type definitions that match the given regular expressions, sorted by relevance:
$ guix system search console font name: console-fonts location: gnu/services/base.scm:729:2 extends: shepherd-root description: Install the given fonts on the specified ttys (fonts are + per virtual console on GNU/Linux). The value of this service is a list + of tty/font pairs like: + + '(("tty1" . "LatGrkCyr-8x16")) relevance: 20 name: mingetty location: gnu/services/base.scm:1048:2 extends: shepherd-root description: Provide console login using the `mingetty' program. relevance: 2 name: login location: gnu/services/base.scm:775:2 extends: pam description: Provide a console log-in service as specified by its + configuration value, a `login-configuration' object. relevance: 2 …
guix package --search, the result is written in
recutils format, which makes it easy to filter the output
(see GNU recutils databases in GNU recutils manual).
Build the operating system described in file, activate it, and switch to it27.
This effects all the configuration specified in file: user accounts, system services, global package list, setuid programs, etc. The command starts system services specified in file that are not currently running; if a service is currently running, it does not attempt to upgrade it since this would not be possible without stopping it first.
This command creates a new generation whose number is one greater than
the current generation (as reported by
list-generations). If that generation already exists, it will be
overwritten. This behavior mirrors that of
(see Invoking guix package).
It also adds a bootloader menu entry for the new OS configuration, —unless --no-bootloader is passed. For GRUB, it moves entries for older configurations to a submenu, allowing you to choose an older system generation at boot time should you need it.
Note: It is highly recommended to run
guix pullonce before you run
guix system reconfigurefor the first time (see Invoking guix pull). Failing to do that you would see an older version of Guix once
Switch to an existing system generation. This action atomically switches the system profile to the specified system generation. It also rearranges the system’s existing bootloader menu entries. It makes the menu entry for the specified system generation the default, and it moves the entries for the other generatiors to a submenu, if supported by the bootloader being used. The next time the system boots, it will use the specified system generation.
The bootloader itself is not being reinstalled when using this command. Thus, the installed bootloader is used with an updated configuration file.
The target generation can be specified explicitly by its generation number. For example, the following invocation would switch to system generation 7:
guix system switch-generation 7
The target generation can also be specified relative to the current
generation with the form
“3 generations ahead of the current generation,” and
“1 generation prior to the current generation.” When specifying a
negative value such as
-1, you must precede it with
prevent it from being parsed as an option. For example:
guix system switch-generation -- -1
Currently, the effect of invoking this action is only to switch
the system profile to an existing generation and rearrange the
bootloader menu entries. To actually start using the target system
generation, you must reboot after running this action. In the future,
it will be updated to do the same things as
like activating and deactivating services.
This action will fail if the specified generation does not exist.
Switch to the preceding system generation. The next time the system
boots, it will use the preceding system generation. This is the inverse
reconfigure, and it is exactly the same as invoking
switch-generation with an argument of
Currently, as with
switch-generation, you must reboot after
running this action to actually start using the preceding system
Build the derivation of the operating system, which includes all the configuration files and programs needed to boot and run the system. This action does not actually install anything.
Populate the given directory with all the files necessary to run the operating system specified in file. This is useful for first-time installations of GuixSD. For instance:
guix system init my-os-config.scm /mnt
copies to /mnt all the store items required by the configuration specified in my-os-config.scm. This includes configuration files, packages, and so on. It also creates other essential files needed for the system to operate correctly—e.g., the /etc, /var, and /run directories, and the /bin/sh file.
This command also installs bootloader on the target specified in my-os-config, unless the --no-bootloader option was passed.
Build a virtual machine that contains the operating system declared in file, and return a script to run that virtual machine (VM). Arguments given to the script are passed to QEMU as in the example below, which enables networking and requests 1 GiB of RAM for the emulated machine:
$ /gnu/store/…-run-vm.sh -m 1024 -net user
The VM shares its store with the host system.
Additional file systems can be shared between the host and the VM using
--expose command-line options: the former
specifies a directory to be shared with write access, while the latter
provides read-only access to the shared directory.
The example below creates a VM in which the user’s home directory is accessible read-only, and where the /exchange directory is a read-write mapping of $HOME/tmp on the host:
guix system vm my-config.scm \ --expose=$HOME --share=$HOME/tmp=/exchange
On GNU/Linux, the default is to boot directly to the kernel; this has the advantage of requiring only a very tiny root disk image since the store of the host can then be mounted.
--full-boot option forces a complete boot sequence, starting
with the bootloader. This requires more disk space since a root image
containing at least the kernel, initrd, and bootloader data files must
be created. The
--image-size option can be used to specify the
size of the image.
Return a virtual machine, disk image, or Docker image of the operating
system declared in file that stands alone. By default,
guix system estimates the size of the image needed to store
the system, but you can use the --image-size option to specify
a value. Docker images are built to contain exactly what they need, so
the --image-size option is ignored in the case of
You can specify the root file system type by using the
--file-system-type option. It defaults to
vm-image, the returned image is in qcow2 format, which
the QEMU emulator can efficiently use. See Running GuixSD in a VM,
for more information on how to run the image in a virtual machine.
disk-image, a raw disk image is produced; it can be
copied as is to a USB stick, for instance. Assuming
the device corresponding to a USB stick, one can copy the image to it
using the following command:
# dd if=$(guix system disk-image my-os.scm) of=/dev/sdc
docker-image, a Docker image is produced. Guix builds
the image from scratch, not from a pre-existing Docker base image. As a
result, it contains exactly what you define in the operating
system configuration file. You can then load the image and launch a
Docker container using commands like the following:
image_id="$(docker load < guixsd-docker-image.tar.gz)" docker run -e GUIX_NEW_SYSTEM=/var/guix/profiles/system \\ --entrypoint /var/guix/profiles/system/profile/bin/guile \\ $image_id /var/guix/profiles/system/boot
This command starts a new Docker container from the specified image. It
will boot the GuixSD system in the usual manner, which means it will
start any services you have defined in the operating system
configuration. Depending on what you run in the Docker container, it
may be necessary to give the container additional permissions. For
example, if you intend to build software using Guix inside of the Docker
container, you may need to pass the --privileged option to
Return a script to run the operating system declared in file within a container. Containers are a set of lightweight isolation mechanisms provided by the kernel Linux-libre. Containers are substantially less resource-demanding than full virtual machines since the kernel, shared objects, and other resources can be shared with the host system; this also means they provide thinner isolation.
Currently, the script must be run as root in order to support more than a single user and group. The container shares its store with the host system.
As with the
vm action (see guix system vm), additional file
systems to be shared between the host and container can be specified
using the --share and --expose options:
guix system container my-config.scm \ --expose=$HOME --share=$HOME/tmp=/exchange
Note: This option requires Linux-libre 3.19 or newer.
options can contain any of the common build options (see Common Build Options). In addition, options can contain one of the following:
Consider the operating-system expr evaluates to. This is an alternative to specifying a file which evaluates to an operating system. This is used to generate the GuixSD installer see Building the Installation Image).
Attempt to build for system instead of the host system type.
This works as per
guix build (see Invoking guix build).
Return the derivation file name of the given operating system without building anything.
disk-image action, create a file system of the given
type on the image.
When this option is omitted,
guix system uses
--file-system-type=iso9660 produces an ISO-9660 image, suitable
for burning on CDs and DVDs.
disk-image actions, create an image
of the given size. size may be a number of bytes, or it may
include a unit as a suffix (see size specifications in GNU Coreutils).
When this option is omitted,
guix system computes an estimate
of the image size as a function of the size of the system declared in
Make file a symlink to the result, and register it as a garbage collector root.
Skip pre-installation safety checks.
guix system init and
reconfigure perform safety checks: they make sure the file systems that
appear in the
operating-system declaration actually exist
(see File Systems), and that any Linux kernel modules that may be
needed at boot time are listed in
initrd-modules (see Initial RAM Disk). Passing this option skips these tests altogether.
Apply strategy when an error occurs when reading file. strategy may be one of the following:
Report the error concisely and exit. This is the default strategy.
Likewise, but also display a backtrace.
Report the error and enter Guile’s debugger. From there, you can run
commands such as
,bt to get a backtrace,
display local variable values, and more generally inspect the state of the
program. See Debug Commands in GNU Guile Reference Manual, for
a list of available debugging commands.
Note: All the actions above, except
init, can use KVM support in the Linux-libre kernel. Specifically, if the machine has hardware virtualization support, the corresponding KVM kernel module should be loaded, and the /dev/kvm device node must exist and be readable and writable by the user and by the build users of the daemon (see Build Environment Setup).
Once you have built, configured, re-configured, and re-re-configured your GuixSD installation, you may find it useful to list the operating system generations available on disk—and that you can choose from the bootloader boot menu:
List a summary of each generation of the operating system available on
disk, in a human-readable way. This is similar to the
--list-generations option of
(see Invoking guix package).
Optionally, one can specify a pattern, with the same syntax that is used
guix package --list-generations, to restrict the list of
generations displayed. For instance, the following command displays
generations that are up to 10 days old:
$ guix system list-generations 10d
guix system command has even more to offer! The following
sub-commands allow you to visualize how your system services relate to
Emit in Dot/Graphviz format to standard output the service extension graph of the operating system defined in file (see Service Composition, for more information on service extensions.)
$ guix system extension-graph file | dot -Tpdf > services.pdf
produces a PDF file showing the extension relations among services.
Emit in Dot/Graphviz format to standard output the dependency graph of shepherd services of the operating system defined in file. See Shepherd Services, for more information and for an example graph.
This action (and the related actions
roll-back) are usable only on
systems already running GuixSD.