Change:
, buildPackages }: stdenv.mkDerivation rec { <del> name = "lkl-2018-08-22"; rev  = "5221c547af3d29582703f01049617a6bf9f6232a"; </del> <ins> pname = "lkl"; version = "2019-06-20"; rev  = "0a4ebeadad12b94db665b8daf30e44e949a02d90"; </ins> outputs = [ "dev" "lib" "out" ];

Discussion:
Not sure this is the correct repo. Will refile if needed, just let me know. The wiki at links to http://nixos- maintained by , and the armv7l image is affected by , meaning that it gets wedged and you cannot upgrade. (Aside: The aarch64 image has nix 2.1.1, which is unaffected, but the disk image does not match the checksum in SHA256SUMS.) Download , it to a micro sd and stick it in a pi 3b. Most invocations of will hit something that wants an archive, and from there it's impossible to proceed due to the linked bug above. It is possible (if you have a day or so) to get a bootstrap toolchain from outside nix, install it, build nix and all its dependencies by hand, and then try to use an external nix to fix the nixos install. I have attached my notes to this issue:
Any luck on this?
Oof, I think I am hitting this. It wedges up here (for me) every time: Could this be worked around using an older arm7 image? Might you have one laying around,
If you have a lot of patience, can you try the bootstrapping instructions I put in the .txt link at the top of the issue? That builds a newer nix from source.
looking over those instructions, it looks involved! I'm not sure I have the time to put into it. Do you mean though that the issue is fixed in nixpkgs master? In that case, would a new arm image be all that is needed? If so, how are these images made? I have a working arm7 machine if that is helpful.
Ugh, sorry. I just saw . I will give them a try when my poor little arm board has finished its (unrelated) . It may be a minute.
I didn't know about the build-your-own-image instructions. I was talking about the long and slow manual build of nix. At least it looks like you have a way forward.
I tried setting up an aarch64 build host with qemu: Could you please regenerate the installer images?
The aarch64 images are now generated on NixOS' hydra instance
I'm having the same problem with the Hydra builds.

Is there an example qemu command I could try?
I never have used the sdimage with qemu, but I have used the (relatively) new . Using this, and a (look for the second output, its name should end with ) I was able to boot an aarch64 qemu, either with emulation (on x86_64) or even virtualisation (on an aarch64 host).
Hm, I wonder if someone can help me. My machine finally finished its update! And now I am trying to make my own sd-image. My problem is with , which refuses to build on armv7. After adding to its list of platforms, I get the build error: Which seems maybe related to Their fix seems to specifically look for android though, which won't help of course. Any ideas? Thinking differently, the package needs only to make use of the command inside the builder. Is there an alternative way to get this effect? I guess we cannot just mount the fs and things to it in the build environment?
(But I am also a little confused. How did this ever work to build the armv7 images??)
in case you have any ideas! I must be missing something obvious.
, hmmm, this would be an annoyance if there was a regression on an unsupported, but working, platform like armv7l; it's harder to work on, test, and fix.
Ooooh, thanks! Perhaps I can try building an image using a commit from just before that change was merged.
Success! I reverted the change you linked me to and rebuilt. The resulting image boots nicely on my hardware. If anyone needs a working armv7 sd image, and knows of a place I could stash it, let me know!
I would love access to it, if possible. :)
Hi sorry this took a long time. I've to on my nixpkgs fork. You should be able to just whack this on an SD card like the normal image.
Thanks very much, I can confirm that your release works great for me. Strictly speaking, I tested it on an eMMC card rather than an SD card.
I just encountered this issue, except on armv6l, not armv7l, so I wasn't able to avoid it by using 's image.

However, I thought I would point out that if you have another suitable build host with nix installed, you can use it to cross-compile a newer version of nix. For : or for : You can then use or and to copy the required derivations onto the arm device. (At the moment, you get a few hundred MB of debug and host libs in your closure, but it's not really a problem in this instance) This should be less involved and considerably faster (on my build host, the cross toolchain was actually fetched from , saving a lot of time) than the manual steps detailed by
is broken on armv7l when resulting filesystem is bigger than 2G. Why not use option of when creating image? will not be needed anymore so less stuff to compile and maintain.