When gummiboot.timeout == null, the menu will still be skipped.
When gummiboot.timeout == 0, the menu will also be skipped.
The only way to show the menu 'indefinitely' is to show it a long time.
During install, the bootloader script gets run inside a chroot after the
/etc/group bind-mount is unmounted. Since we're not doing any building,
this should be safe, but really nix should just not care if the group
does not exist when no build is needed.
Fixes#5494
The gummiboot-builder.py script is expecting the @timeout@ metavar to be
substituted for either an empty string (in the case where a user has
left the timeout unset) or the actual value set in the system
configuration.
However, the config.boot.loader.gummiboot.timeout option defaults to
'null', and due to the way pkgs.substituteAll works, the substitution
for '@timeout@' is _never_ set to the empty string. This causes the
builder script to put a bogus line into /boot/loader/loader.conf:
timeout @timeout@
Fix this by explicitly setting 'timeout' to the empty string when it's
unset in the system configuration.
Signed-off-by: Josh Cartwright <joshc@eso.teric.us>
This reverts commit 469f22d717, reversing
changes made to 0078bc5d8f.
Conflicts:
nixos/modules/installer/tools/nixos-generate-config.pl
nixos/modules/system/boot/loader/grub/install-grub.pl
nixos/release.nix
nixos/tests/installer.nix
I tried to keep apparently-safe code in conflicts.
If /boot is a btrfs subvolume, it will be on a different device than /
but not be at the root from grub's perspective. This should be fixed in
a nicer way by #2449, but that can't go into 14.04.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
Without this the HTML manual and manpage is quite unreadable (newlines
are squashed so it doesn't look like a list anymore).
(Unfortunately, this makes the source unreadable.)
You can now say:
systemd.containers.foo.config =
{ services.openssh.enable = true;
services.openssh.ports = [ 2022 ];
users.extraUsers.root.openssh.authorizedKeys.keys = [ "ssh-dss ..." ];
};
which defines a NixOS instance with the given configuration running
inside a lightweight container.
You can also manage the configuration of the container independently
from the host:
systemd.containers.foo.path = "/nix/var/nix/profiles/containers/foo";
where "path" is a NixOS system profile. It can be created/updated by
doing:
$ nix-env --set -p /nix/var/nix/profiles/containers/foo \
-f '<nixos>' -A system -I nixos-config=foo.nix
The container configuration (foo.nix) should define
boot.isContainer = true;
to optimise away the building of a kernel and initrd. This is done
automatically when using the "config" route.
On the host, a lightweight container appears as the service
"container-<name>.service". The container is like a regular NixOS
(virtual) machine, except that it doesn't have its own kernel. It has
its own root file system (by default /var/lib/containers/<name>), but
shares the Nix store of the host (as a read-only bind mount). It also
has access to the network devices of the host.
Currently, if the configuration of the container changes, running
"nixos-rebuild switch" on the host will cause the container to be
rebooted. In the future we may want to send some message to the
container so that it can activate the new container configuration
without rebooting.
Containers are not perfectly isolated yet. In particular, the host's
/sys/fs/cgroup is mounted (writable!) in the guest.
