When installing NixOS on a machine with Windows, the "easiest" solution
to dual-boot is re-using the existing EFI System Partition (ESP), which
allows systemd-boot to detect Windows automatically.
However, if there are multiple ESPs, maybe even on multiple disks,
systemd-boot is unable to detect the other OSes, and you either have to
use Grub and os-prober, or do a tedious manual configuration as
described in the wiki:
https://wiki.nixos.org/w/index.php?title=Dual_Booting_NixOS_and_Windows&redirect=no#EFI_with_multiple_disks
This commit automates and documents this properly so only a single line
like
boot.loader.systemd-boot.windows."10".efiDeviceHandle = "HD0c2";
is required.
In the future, we might want to try automatically detecting this
during installation, but finding the correct device handle while the
kernel is running is tricky.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Move replaceRuntimeDependencies to the replaceDependencies namespace,
where the structure is more consistent with the replaceDependencies
function. This makes space for wiring up cutoffPackages as an option
too.
By default, the system's initrd is excluded. The replacement process does not
work properly anyway due to the structure of the initrd (the files being copied
into it, and it being compressed). In the worst case (which has been observed
to actually occur in practice), a store path makes it into the incompressible
parts of the archive, checksums are broken, and the system won't boot.
Instead of iterating over all replacements and applying them one by one,
use the newly introduced replaceDependencies function to apply them all
at once for replaceRuntimeDependencies. The advantages are twofold in
case there are multiple replacements:
* Performance is significantly improved, because there is only one pass
over the closure to be made.
* Correctness is improved, because replaceDependencies also replaces
dependencies of the replacements themselves if applicable.
Fixes: https://github.com/NixOS/nixpkgs/issues/4336
tpm2.target was functionally useless without these services and this
generator. When systemd-cryptsetup-generator creates
systemd-cryptsetup@.service units, they are ordered after
systemd-tpm2-setup-early.service, not tpm2.target. These services are
themselves ordered after tpm2.target.
Note: The systemd-tpm2-setup(-early) services will serve no *function*
under a normal NixOS system at the moment. Because of their
ConditionSecurity=measured-uki, they will always be skipped, unless
you are building an appliance with the system.build.uki feature. Thus,
these are enabled solely for their systemd unit ordering properties.
Avoid running Python scripts in the root of the package, as this
triggers `os.listdir` on the Nix store directory during import. This
operation can be time-consuming on large store directories
(see issue #283795 for more details).
The issue was initially fixed in #284153 but was reverted in #306339.
Co-authored-by: Sönke Hahn <soenkehahn@gmail.com>
The Rust `switch-to-configuration-ng` rewrite was carefully written
to be compatible with the original Perl script, has been checked
against NixOS VM tests, and has been available on an opt‐in basis
for testing for the 24.05 release cycle.
The next step towards replacing the Perl script entirely is to
switch it on by default so that we can get real‐world testing from
a much greater number of users. Maintaining two implementations in
parallel is becoming a burden; we are having to adjust the systemd
service activation behaviour slightly to fix a long‐standing bug,
and backporting the changes to the Perl script is an unpleasant
process. We will do it anyway to ensure that the Rust and Perl
implementations keep parity with each other throughout the 24.11
release cycle, but we think the time has come to flip the switch.
Taking this step now will give us two to three months to test this in
the wild before the 24.11 release and gain confidence that there are
no regressions. If any non‐trivial problems arise before the final
release, we will revert to the Perl implementation by default. Doing
this switch ASAP will help to disentangle any problems that might
arise from the Rust implementation from problems that arise from the
systemd service activation changes, or the upcoming switch to using
systemd in stage 1 by default.
The main concern that was raised about replacing the Perl script in the
PR that added `switch-to-configuration-ng` was that it is currently
possible to run NixOS on systems that cannot natively host a Rust
compiler. This does not apply to any platforms that have official
support from NixOS, and as far as I know we do not know of any such
systems with users that are not cross‐compiling anyway.
My understanding is that these systems are already broken by default
anyway, as `systemd.shutdownRamfs.enable` is on by default and uses
`make-initrd-ng`, which is also written in Rust. Switching the default
while keeping the Perl implementation around will give us at least
an entire release cycle to find out if there are any users that will
be affected by this and decide what to do about it if so.
There is currently one known inconsistency between
the Perl and Rust implementations, as documented in
<https://github.com/NixOS/nixpkgs/issues/312297>; the Rust
implementation has more accurate handling of failed systemd units.
We slightly adjust the semantics of `system.switch.enable{,Ng}` to
not conflict with each other, so that `system.switch.enableNg` is
on by default, but turning off `system.switch.enable` still results
in no `switch-to-configuration` implementation being used. This
won’t break the configuration of anyone who already opted in to
`system.switch.enableNg` and is probably how the option should have
worked to begin with.
