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
