Change:
(<replaceable>user@host</replaceable>). You can also set ssh options by defining the <envar>NIX_SSHOPTS</envar> environment variable. </para> <ins> <para> Note that <command>nixos-rebuild</command> honors the <literal>nixpkgs.crossSystem</literal> setting of the given configuration but disregards the true architecture of the target host. Hence the <literal>nixpkgs.crossSystem</literal> setting has to match the target platform or else activation will fail. </para> </ins> </listitem> </varlistentry>

Discussion:
Trying to use with to install onto a remote host. Fails at what I think is the last hurdle. Here's the end of the output: Steps to reproduce the behavior: New system installed on remote machine. Command was run on a x86-64, target host is an i686. Trying to do this, I had previously encountered bug which I worked around as I described in that issue. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Here's the metadata for the remote host:
tried setting to the remote machine: that fails with "cannot execute binary file" when trying to run an version of (presumably on the remote machine). I can't see a switch or env var for this, but should I be telling the target architecture? I had presumed it would interrogate the target host...
I don't have any experience in cross compilation. It seems that is treated as a bash script even though it's actually a Perl script. Could you try to run (don't worry, if you don't pass any arguments to this script it won't do anything) on both of your computers? From a quick look I didn't notice anything at odds with the way calls .
Running on the : and on the : the shebang for is: and running that binary on the gives: the same binary behaves as expected on the (prints help) so it's trying to use an binary on an ?
Okay! That is valuable output! Yes, I agree that it's trying to use an binary on an . A workaround fix for that concrete issue would be to change the shebang line into , which would (hopefully) find the correct perl to use at runtime. However, that's probably not the best solution. The shebang line is specified in [nixos/modules/system/activation/switch-to-] as , which is in [nixos/modules/system/activation/top-] then rewritten by a call to so that gets replaced by the path to whatever perl package which is currently in evaluation scope. I hope that people who are more familiar with cross compilation can use this information to devise a good fix :-)
I tried to reproduce this here.

Since all my machines are x86-64, I cannot use and instead tried cross compiling with where has the following contents: However, this approach produces a file which references the correct (i686) perl. I still assume that someone who is knowledgeable with the nixpkgs cross compilation architecture could resolve this very quickly, but time permitting I will also continue to think about this. do you have tuits to raise this issue over at our ?
I have raised this on the discourse
has the answer I believe: and just tell where to run things without any regard to their architecture. You need to make sure that your system configuration is cross compiled properly when going from x86_64 to i686. When using an host as the builder you need to make sure that nixpkgs / the system configuration knows it's supposed to be built on as well.
Oh cool, thank you I didn't realize I had the solution :-) So we are looking at a documentation bug, not at an implemention bug. it looks like you need to add a section similar to my example in the relevant
Thanks! I have inserted such a section and this almost works now, except that the cross-compile fails on with failing on missing , which I'll investigate separately. A caveat in the docs would be nice, as would be a warning at some point that an attempt is being made to install an unworkable config.