Use the store directory for the devicetree package containing the
desired DTB when installing to the ESP. This allows for more than one
NixOS generation containing differing DTBs to coexist on the same ESP
(similar to how we can have multiple kernels & initrds). This change
removes the assumption that the filepath passed to `copy_from_file` is a
file that lives at the toplevel of a nix output path (which prior to the
systemd-boot DTB support was the case for the kernel and initrd
derivations).
When building an image, rather than operating on a real partition,
there's no need to have sfdisk tell the kernel to reread the partition
table. This also avoids a call to sync(2), which could be very
expensive depending on what other IO is going on on the system at the time.
Strongly inspired by the forgejo counterpart[1], for the following
reasons:
* The feature is broken with the current module and crashes on
authentication with the following stacktrace (with a PAM service
`gitea` added):
server # Stack trace of thread 1008:
server # #0 0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
server # #1 0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
server # #2 0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
server # #3 0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
server # #4 0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
server # #5 0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
server # #6 0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
server # #7 0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
server # #8 0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
server # ELF object binary architecture: AMD x86-64
server #
server # [ 42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
server # [ 42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost= user=snenskek
It only worked after turning off multiple sandbox settings and adding
`shadow` as supplementary group to `gitea.service`.
I'm not willing to maintain additional multiple sandbox settings for
different features, especially given that it was probably not used for
quite a long time:
* There was no PR or bugreport about sandboxing issues related to
PAM.
* Ever since the module exists, it used the user `gitea`, i.e. it had
never read-access to `/etc/shadow`.
* Upstream has it disabled by default[2].
If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.
[1] 07641a91c9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module
This adds a new `imageStream` option that can be used in conjunction
with `pkgs.dockerTools.streamLayeredImage` so that the image archive
never needs to be materialized in the `/nix/store`. This greatly
improves the disk utilization for systems that use container images
built using Nix because they only need to store image layers instead of
the full image. Additionally, when deploying the new system and only
new layers need to be built/copied.
Test out both nix upgrade-nix and a NixOS upgrade.
Inject a fake fallback-paths.nix assuming a stable -> latest upgrade.
The NixOS upgrade does not use nixos-rebuild switch due to the
cost+annoyance of the instantiation needing
system.includeBuildDependencies.
After upgrading to 3.5.0 we noticed, that registering would redirect to
the login page and not work at all. At the same time the admin user was
unable to access its user settings.
This issue could be tracked back to the template cache, that must be
invalidated between release upgrades.
provision # [ 8.223448] (kanidmd)[819]: kanidm.service: Failed to set up mount namespacing: /ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ofborg-evaluator-1/nixos/tests/common/acme/server:
No such file or directory
This should fix errors where /etc is reported to be busy and thus cannot
be unmounted.
Another solution we can consider if this doesn't work out as we expect
is to forcefully unmount /etc.
I've observed that sometimes the overlay mount unit does not get started
when using wantedBy. requiredBy makes this relationship stricter and if
necessary will restart the initrd-fs.target and thus ensure that when
this target is reached /etc has alredy been mounted. This is in line
with the description of initrd-fs.target in systemd.special:
> Thus, once this target is reached the /sysroot/ hierarchy is fully set up
This was broken by the Rust 1.80 upgrade, and is an old version that
we’d have to patch to keep working.
We have already done the 0.4 → 0.5 update without keeping around
the old version or adding in any additional `stateVersion` logic
in <https://github.com/NixOS/nixpkgs/pull/280221>. As a result,
migration for 0.3 users is going to be a little awkward. I’ve done
my best to provide comprehensive instructions for anyone who hasn’t
already bumped to 0.4.
It is probably a footgun to add `stateVersion` logic for any
package that makes backwards‐incompatible schema changes and only
supports migration from the immediately previous version. Users
won’t get migrated by default and we have to either package and
maintain an endlessly growing list of old versions or add complicated
instructions like this. It’s not really practical for us to support
a significantly better migration story than upstream does.
- Split desktop into desktop-basics (basic keybind & app launching) and
desktop-appinteractions (one applications triggering something in another) due to timeouts
- Wrap machine.wait_for_text to wait 10 seconds before starting
The 10 second delay improves runtime dramatically on weaker hardware. In desktop-ayatana-indicators
on my aarch64 laptop, runtime was cut down by 818,41 seconds (~ 14 minutes).
Hopefully helps abit with timeout issues on ARM :(
[UWSM](https://github.com/Vladimir-csp/uwsm) is a session manager that wraps a wayland
window compositor with useful systemd units like `graphical-session-pre.target`,
`graphical-session.target`, `xdg-desktop-autostart.target`.
This is useful for Wayland Compositors that do not start
these units on these own.
Example for Hyprland:
```nix
programs.hyprland.enable = true;
programs.uwsm.enable = true;
programs.uwsm.waylandCompositors = {
hyprland = {
compositorPrettyName = "Hyprland";
compositorComment = "Hyprland compositor managed by UWSM";
compositorBinPath = "/run/current-system/sw/bin/Hyprland";
};
};
```
Co-authored-by: Kai Norman Clasen <k.clasen@protonmail.com>
The mkfs.erofs utility has a lot of output by default that slows down
running tests. We don't need to capture any of the output from
mkfs.erofs, so we can suppress it.
The cgitrc file allows list of values to be set for some keys as
multiple definition lines.
This allows setting multiple "css" files to include or multiple
"readme" branch and file lookup paths to be set.
The minimum reproduction for the problem I'm trying to solve is that
the following NixOS test with a trivial NixOS container:
```
{ inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/24.05";
flake-utils.url = "github:numtide/flake-utils/v1.0.0";
};
outputs = { flake-utils, nixpkgs, self, ... }:
flake-utils.lib.eachDefaultSystem (system: {
checks.default = nixpkgs.legacyPackages."${system}".nixosTest {
name = "test";
nodes.machine.containers.tutorial.config = { };
testScript = "";
};
});
}
```
… fails with the following error message:
```
error: Neither nodes.machine.nixpkgs.hostPlatform nor the legacy option nodes.machine.nixpkgs.system has been set.
You can set nodes.machine.nixpkgs.hostPlatform in hardware-configuration.nix by re-running
a recent version of nixos-generate-config.
The option nodes.machine.nixpkgs.system is still fully supported for NixOS 22.05 interoperability,
but will be deprecated in the future, so we recommend to set nodes.machine.nixpkgs.hostPlatform.
```
The root of the problem appears to be that in
`nixos/modules/virtualisation/nixos-containers.nix` there is support
for deriving the guest's `nixpkgs.hostPlatform` or
`nixpkgs.localSystem` from the corresponding host's values, but this
doesn't work if the host sets `nixpkgs.pkgs` instead of one of those
values. In fact, this is what happens when using `pkgs.nixosTest`
(which sets `nixpkgs.pkgs` in
`pkgs/build-support/testers/default.nix`).
The solution I went with was to forward the `nixpkgs.pkgs` setting from
the host to the guest, but only if it is defined (matching the same
treatment as `nixpkgs.hostPlatform` and `nixpkgs.localSystem`.
This splits the 3rdparty drivers into seperate
packages as recommended by upstream. This also
allows to build a indi-full equivalent with only
the needed drivers. Also add indi-full-nonfree
with all the nonfree drivers. And remove them
from indi-full.
https://forgejo.org/docs/latest/user/authentication/#pam-pluggable-authentication-module
PAM support has to be enabled at compile time and upstream considers it
opt-in.
Official upstream binaries have it disabled.
We enabled it by default because we simply inherited most of it from
Gitea when the split in nixpkgs happened.
Reasons why it had been enabled in nixpkgs for Gitea are unknown.
See 9406f240a7.
There is reason to believe not a single Forgejo instance running on
NixOS uses this feature because it literally segfaults due to our
sandboxing.
Although CDI should be used in order to not require container runtime
wrappers anymore, fix the nvidia-container-runtime integration with
Docker for cases when Docker < 25.
Although kubectl has builtin JSONpath support, it is only supported
partially and the support varies between different versions. While using
JSONpath in tests worked for some versions, it failed for others. This
contribution replaces the problematic JSONpath usages with the jq JSON
processor.
