initrd-nixos-activation ran the closure's prepare-root unconditionally. For a
non-NixOS init= there is no prepare-root, so the service failed, and since
initrd-switch-root.service requires it, switch-root never ran and the machine
dropped to the emergency shell. This broke init=/bin/sh recovery, and microVMs
that serve /nix/store over virtiofs and boot an arbitrary binary as init=.
initrd-find-nixos-closure already detects this and writes a non-empty NEW_INIT
to /etc/switch-root.conf (empty for a NixOS init). Read it via the same
EnvironmentFile= initrd-switch-root uses and skip activation when it's set, so
a non-NixOS init= switch-roots into its target directly. The NixOS path is
unchanged.
Also add a test booting a non-NixOS init=. It uses a store path rather than
/bin/sh: a real root already has /bin/sh and an os-release, but a fresh test
root has neither, so the test uses a tmpfs root and writes os-release first.
Assisted-by: Claude:claude-opus-4-8
rustc allows code to perform compile-time tests against target_env [0],
which is a function of the target triple. There isn't provision in
Nixpkgs for learning target_env, however. That doesn't affect rustc's
evaluation of cfg guards in Rust code - rustc knows perfectly well what
target_env is - but it _does_ affect the env vars passed to a build
script set by buildRustCrate, which is presently hard-coded to gnu, and
also affects any Nix code looking to branch on target_env.
Being able to access target_env is very relevant to, for example, WASI
as (using Rust terminology) wasm32-wasip1 and wasm32-wasip2 differ only
by target_env, with identical target_arch and target_os values. Properly
reflecting target_env may also fix some random musl issues if you're a
bit lucky.
This commit adds a new attr, rust.platform.env, which reflects the
target_env that rustc will set for the target, and wires it up in
buildRustCrate. In isolation, this change mostly only affects build
scripts checking target_env, but crate2nix will greatly benefit from
being able to accurately resolve the dep graph (which can also vary
depending on target_env).
The target triple -> target_env function resists Kolmogorov compression:
it's irregular and, though there are some patterns, there are lots of
special cases. So, I have done the stupidest possible thing and scraped
out all of the targets with non-empty target_env values and dumped that
into an attrset. This attrset will progressively get out of date as
rustc adds new platforms, but updating it should be simple enough - I've
included the generation script as a comment.
There are some other configuration options not being reflected in Nix. I
have left those alone, but, in the future, maybe this can be extended to
just dumping all of them into an attrset and then reflecting them in
rust.platform. It might even make sense to convert the existing code
producing rust.platform to just looking up from an attrset and to 'do
what rustc does'.
I would have liked to have added a test targetting a platform with a
non-empty non-GNU target_env, but all of the yaks were quite hairy.
Fixes https://github.com/NixOS/nixpkgs/issues/436832
[0]: https://doc.rust-lang.org/reference/conditional-compilation.html#r-cfg.target_env
