The approach taken in [1] breaks down as soon as vmRunCommand is
manually called with an overriden TMPDIR, like disko does it. /build
will just not be available.
By moving the .attrs.sh file into the xchg folder explicitly, we can all
the "exchange infrastructure" the same as before, thus avoid more
breakage.
This reverts some parts of [1].
[1]: 97ed6b4565
In [1] we started sourcing stdenv/setup in stage2Init to allow for
structuredAttrs. We failed to take the changed NIX_BUILD_TOP etc.
variables into account. We need to load stdenv/setup after changing
them, because the structuredAttrs startup code makes use of it.
[1]: 97ed6b4565
The export to saved-env was very intentionally done at the very
beginning of vmRunCommand, even jumping through extra hoops just to
avoid the PATH variable from polluting the saved variable.
In 26eba25577 we loaded stdenv in the
wrong place, we should do it after saving the previous environment. This
is also more consistent with the order of how we load those values back
in stage2Init.
Those were left-over after 97ed6b4565.
This also cleans up some confusion around TMPDIR. We had the following
lines:
mkdir xchg
...
cd $TMPDIR
...
path=$TMPDIR/xchg
Those only worked because the **current directory** is the same as
$TMPDIR. Both are /build by default. To refer to the same directory in
two different ways is very confusing at best.
Commit 97ed6b4565 broke the systemd-boot
tests (among others) because of the `hwclock -s` invocation. This was
broken for a while, but not noticed because we didn't have a `set -e`
before.
The error
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
MAY be related to an open QEMU bug[1]: I can't reproduce the error on
aarch64-linux and x86_64-linux with `partitionTableType = "legacy";`.
Also, the issue disappears on x86_64-linux when adding `--directisa`.
However, the invocation was added in f73ff0529e
10 years ago which didn't give any reasoning or pointer to what KVM bug
this may be. Given that this must have happened on an ancient version,
we agreed on removing it altogether[2].
[1] https://gitlab.com/qemu-project/qemu/-/issues/1762
[2] https://github.com/NixOS/nixpkgs/pull/354535#issuecomment-2500791222
