mirror of
https://github.com/NixOS/nixpkgs.git
synced 2025-11-17 21:25:19 +01:00
Consider a user wanting to set up the Linux builder for the first time,
but with a slightly more generous allocation of resources compared to
the default. They'll do something like this:
```
{
virtualisation.cores = 3;
virtualisation.darwin-builder = {
diskSize = 40 * 1024;
memorySize = 4 * 1024;
};
}
```
This will fail with an error like this:
```
error: a 'aarch64-linux' with features {} is required to build '/nix/store/3acpgmwqwnk8g2gc5r05ar2lvmn01b8a-builder.pl.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}
```
But why would they have to rebuild the NixOS system?! All they did was
change the arguments passed to QEMU, and nothing those options control
would affect the NixOS configuration itself... right?
`config.system.build.toplevel` is defined with `allowSubstitutes` set to
`false` by default, which makes it so that the toplevel can't be
substituted if Nix is trying to use it "directly." So because the above
example would have to rebuild the VM runner, which references toplevel
directly, Nix refuses to substitute it, unless `always-allow-substitutes
= true` is set as a Nix option. (In the case where the QEMU options
aren't changed at all, Nix just substitutes the runner, which sidesteps
this issue as the runner itself doesn't use toplevel as an input.)
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| config | ||
| hardware | ||
| i18n/input-method | ||
| image | ||
| installer | ||
| misc | ||
| profiles | ||
| programs | ||
| security | ||
| services | ||
| system | ||
| tasks | ||
| testing | ||
| virtualisation | ||
| module-list.nix | ||
| rename.nix | ||