This will ensure reproducibility between different nixos systems, where
one system has store optimization enabled (which will hardling similar
files in the nix store) and the other doesn't. Without the flag, the
same image, built on the two different systems, will have a different
number of inodes. The flag will dereference hardlinks and copy them
into the image as different inodes.
Signed-off-by: Paul Meyer <katexochen0@gmail.com>
This allows users to keep using `docker run --gpus`. Despite CDI is
the recommended way to expose GPU's to containers nowadays, allow
users to keep using the old `--gpus` method.
Integrated the flake container setup into the spawn script for systemd-nspawn.
The trickiest part of this was ensuring the underlying per-container is built.
With the .conf file created, running `nixos-container update` creates all the necessary per-container structure.
We call this command at start to ensure the structure is created only if the per-container system isnt there.
Note: This also means the flake gets updated to branch HEAD when the container is started for the first time.
While the nixos-container command allows for the creation of containers pointing to a flake, the declarative module doesn't have this option.
Adds the flake option for nixos-container declarative approach. Creates the /etc/nixos-container .conf file similar to how the command preforms it.
Upstream, intentionally or not, no longer appends the EFI image
with a .pad section for us to hook the rest of the UKI to. This
simply dehardcodes .pad from the awk script, instead using the
very last section in the binary. (Currently .reloc)
Co-authored-by: Yaroslav Bolyukin <iam@lach.pw>
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
By being in sync with the pname, it makes it easier to walk back from
the pname that shows in the /nix/store back to the attribute.
This change should not cause any rebuild.
This patch adds a NixOS test for Limine on BIOS systems. It also fixes
some formatting in `nixos/lib/make-disk-image.nix`.
Signed-off-by: John Titor <50095635+JohnRTitor@users.noreply.github.com>
This patch adds the option `virtualisation.useBootPartition` which
creates a separate boot partition on BIOS systems using the new
`legacy+boot` partition layout type in `nixos/lib/make-disk-image.nix`.
After running this configuration for a while, we
noticed that the containers didn't get back up once and the services
failed with the following error:
Error: current system boot ID differs from cached boot ID; an unhandled reboot has occurred.
This is hard to reproduce and seems to be a timing issue. However,
the logs indicated another issue that this patch now solves:
* The ExecStartPost= indicated that the user session got stopped before
which is required or sdnotify=healthy. Add explicit ordering for
user@. This unfortunately requires a statically declared uid.
When using e.g. GitLab as container registry, the token name may be the
username. However, the token name can contain special characters
including spaces breaking the registry login like this:
Apr 25 15:35:48 test42 pre-start[294091]: image doesn't exist locally and login failed
Apr 25 15:35:52 test42 pre-start[294289]: Error: accepts at most 1 arg(s), received 2
Apr 25 15:35:52 test42 pre-start[294297]: Error: registry.example.com/foo/bar/baz: image not known
Applying `escapeShellArg` on it fixes the problem.
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant openstack-zfs --flake .#my-host`
...for filesystem and bootloader options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant google-compute-config --flake .#my-host`
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant digital-ocean --flake .#my-host`
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant azure --flake .#my-host`
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant hyperv --flake .#my-host`
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant common --flake .#my-host`
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant kubevirt --flake .#my-host`
...for filesystem and options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant virtualbox --flake .#my-host`
...for filesystem options. Before this change, users would typically encounter conflicting option definitions when trying to build an image for a generic nixos closure, i.e. `nixos-rebuild build-image --image-variant vmware --flake .#my-host`
...for filesystem options. Before this change, users would typically encounter conflicting option definitions when trying to build an image for a generic nixos closure, i.e. `nixos-rebuild build-image --image-variant qemu --flake .#my-host`
...for filesystem options. Before this change,
users would typically encounter conflicting option definitions
when trying to build an image for a generic nixos closure, i.e.
`nixos-rebuild build-image --image-variant proxmox --flake .#my-host`
This was an oversight in my commit
d37a3ea1ef, and results in the following
eval warning when proxmox images are used: `Obsolete option
`proxmox.qemuConf.diskSize' is used. It was renamed to
`virtualisation.diskSize'.`
...for filesystem options. Before this change, users would typically encounter conflicting option definitions when trying to build an image for a generic nixos closure, i.e. `nixos-rebuild build-image --image-variant linode --flake .#my-host`
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
This produced an unnecessarily infinitely deep config tree.
The "cut off" option can be written to, but not read from.
Being written to is important, because it allows users to
conveniently define vmVariant config without having to check
isVmVariant.
There's a small chance that someone *reads* from vmVariant config
in their normal config, and for them it will not be possible
to evaluate with `nixos-rebuild build-vm` anymore.
If this is a problem, we could perhaps make the vmVariant root
appear instead of the `throw` error.
This could also be done using mkOption apply.
PR #322282 introduced a regression that causes the previous display of
the ssh host key fingerprints to get directed to the journal rather than
the console (as intended). Thus, the console only logs an empty set of
fingerprints:
-----BEGIN SSH HOST KEY FINGERPRINTS-----
-----END SSH HOST KEY FINGERPRINTS-----
The fix is to reorder the bash statement that invokes ssh-keygen so
that the ssh-keygen output is directed to /dev/console.
I think this is the norm in NixOS modules. This allows to start a
container with '--volatile=overlay --link-journal=host' in order to
persist logs across runs of a container running with a temporary root.
While '--ephemeral' omits '--link-journal=try-guest', it's not possible
to run an ephemeral container when linking the journal:
https://github.com/systemd/systemd/issues/1666
Closes#259770Closes#207050
The motivation for the former is to not execute the container as root,
so you don't have to `sudo -i` to perform podman management tasks.
The idea behind healthchecks is to be able to keep the unit in the
activating state until the container is healthy, only then then unit is
marked as active.
The following changes were necessary:
* Move the ctr-id into `/run/${containerName}` to make podman can
actually write to it since it's now in its RuntimeDirectory.
* Make `sdnotify` option configurable (`healthy` for healthchecks that
must pass, default remains `conmon`).
* Set Delegate=yes for `sdnotify=healthy` to make sure a rootless
container can actually talk to sd_notify[1].
* Add a warning that lingering must be enabled to have a `systemd --user`
instance running which is required for the cgroup support to work
properly.
* Added a testcase for rootless containers with both conmon and
healthchecks.
[1] https://github.com/containers/podman/discussions/20573#discussioncomment-7612481
