Change:
nixStable = callPackage common (rec { pname = "nix"; <del> version = "2.3.14"; </del> <ins> version = "2.3.15"; </ins> src = fetchurl { url = "https://nixos.org/releases/nix/${pname}-${version}/${pname}-${version}.tar.xz"; <del> sha256 = "sha256-cToMnZU3+UpjeiiXnG3clz9zn8Xk+TbB7UbqmLMrlFk="; </del> <ins> sha256 = "sha256-N+MxClX94eUOfUMh0puRgNHp16+cjSEdtqZn5u5OtBA="; </ins> }; boehmgc = boehmgc_nix;

Discussion:
Describe the bug during nixos-install a error appears the person who told me about this is i was using his dotfiles to test i did this in a vm and he did it on hw To Reproduce Steps to reproduce the behavior: a root partition fira-code in to your systemPackages -install Expected behavior install should work Screenshots ! Additional context after or the install will continue until there's a another error of the same type which can be fixed by doing the same thing ! would fix it too I hope this issue will help new people who are searching for a fix Maybe related Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
seen 3 people with the same issue in the last 2 days
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
i've seen this happen ~7 times in the past week here's one just 1 hour ago and theres one in the Nix / NixOS matrix server right now
a workaround by first let it complete and then run
does then re-running fix the issue? Curious if flakification efforts of caused some regressions.
oops, just noticed you posted it as well :)
Going to pin this issue until there's a better resolution of this, but many people have been having this issue.
cc
Maybe, but it can be reproduced without using nixos-install at all. See nix bug:
It's quite possible. The script hasn't seen much iteration over the past few months. Much more likely there's a regression in the
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Did anyone figure this out? I've only be able to complete the installation by commeting out sections of the confiuration; once booted into the new system it worked. The problem must be with and not nix in general.
I'm also currently using a similar workaround. By using a minimal configuration the only derivation that is currently causing the issue in my install-phase config is mailcap-2.1.52. I noticed that by finding the derivations in /mnt/nix/store which have .lock files in place point out at least some of such problematic derivations and they can be fixed by nix-store --repair-path.

Interesting, it was mailcap for me too, that can't be a coincidence. There must be something in common with these derivations that's making Nix fail, but only when invoked from nixos-install.
The bug comes from nixos-install invoking nix-store with a --store path that is not /. I strongly believe that this is a nix bug and not a nixos-install bug.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
might be related to
This happened to me with at least (but only when overridden with ) and . Using indeed worked around it each time. This was with an install script that I used a few months back without issue.
don't remember where I read the issue, but there may be a regression with or lesser likely with , as those are likely to be the only difference between what I said above, and what nixos-install is calling: A temporary fix could be just building it twice, once without and , then again with them supplied. This would essentially be applying the "work-around" listed here. The drawbacks being: configuration has to be evaluated twice, and from a user's perspective, it seems like repeated work to users (technically it is). Fills up local /nix/store, which for the installation devices is tmpfs + overlay (heavy on ram usage):
Yes, definitely a Nix bug. Note that the screenshots show that it's trying to substitute from (not !) and then gets ENOENT on a path that isn't supposed to exist.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
nice workwhen i install error msg “not found xxx-glbc-2.2.1”. is working and installed
It would really help if someone posts a log using
I did a re-install on a new VMware machine using the latest minimal ISO nixos-minimal-21.05.1471.-x86_64-linux and reproduced the issue with nixos-install -vvv flag on. Please find the install log files in this attached zip file.

There are two files: -install-phase1-fails-to-mailcap- is the first run of nixos-install -vvv which fails with "getting attributes of path '/nix/store/rya2s79k5ncqbas09rwhq43lrbr4s3m0-mailcap-2.1.52': No such file or directory". After this failure, I manually removed the .lock file of the mailcap-2.1.52 in /mnt/nix/store and re-ran nixos-install -vvv -install-phase2-finishes- is the log output of the second run, during which the installation finished OK
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Until this issue has a proper fix, and all channels have the fix, please don't unpin this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Work around is no good, I ran out of 'disk' space :-(
How much ram
As a workaround workaround install with a minimal config and then use nixos-enter to choose and edit your config and rebuild
Going to try and copy the store to /mnt and then use for the build command.
Is there an issue in the Nix repo for this? Definitely seems like a bug in the chroot store type implementation.
Well I did some rudimentary testing and while it definitely seems like a bug in chroot stores, EDIT: Nope, I missed the obvious. If the derivation is present on your local store, you don't get the error even if you run i.e. without attempting to copy from local. Whoops.
Was this bisected to a known regression? Just hit that the other day and... I'm surprised we're not all hands on deck finding the cause of the regression. This is a terrible first impression, and this got me concerned even for knowledgeable users. Why? Because I assumed first that my hardware was somehow broken and spent a good hour formatting, re-formatting, verifying the disk for defects, reading dmesg output. On a wild goose chase!

Relatedly, for bisecting, we should probably first figure out a valid test protocol as a NixOS test so we don't get a similar regression in the future. EDIT: (I'm sorry if I missed an all-hands-on-deck kind of situation elsewhere)
I figured out a script to test the issue with chroot stores pretty quickly, and managed to bisect it down to a few commits that wouldn't build nix to test with. EDIT: To clarify, this is bisecting Nix and the issue, not NixOS. But I believe this issue to be the culprit of the NixOS issue. But I was having trouble finding a known-bad commit on master. So I decided to start from the 2.3 maintenance branch, as that's the one I've actually reproduced the issue with. So with good: and bad: , narrowed down to these commits that all just failed to build the nix package to test with for whatever reason and so were skipped: Of those, only actually modifies Nix. And given the commit message, it seems like a likely culprit, though I haven't dug into it yet. Reverting this commit on the version of Nix I was originally testing with (2.3.12) has resolved the issue. And considering I couldn't find a bad commit on master, this looks to me like it's a failed backport to 2.3 or something along those lines.
(We were discussing it a bit in direct messages.) In turn, Nix (2.3) was bumped only a few days before this issue was opened. I can't believe reverting those and going back to 2.3.11 is going to cause more issues than breaking the installer. My recommendation would be to revert this bump, and wait until 2.3.15 drops with a fix. We would still be left with some kind of blind spot to whatever caused this issue* with the installer. Not sure if there's anything we can do to harden the installer tests to spot future similar regressions.
And to be complete, here's the repro I was working on, sorry it's not user friendly and a mess: This verified that reverting to 2.3.11 () indeed directly returns to a working installer image. It should also be usable to validate a future fix fixes the issue.

Since reverting is not the actual final fix.
I couldn’t replicate the exact issue, but I’m fairly confident that it would be fixed by . Do you mind giving it a try?
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
:heavycheckmark: verified only against 21.05, but it does fix the issue; Nix finishes the system build. Tested with: (and Nix back at 2.3.14) (I do not know if the issue exists on unstable.)
Can also confirm that fixed the issue in my test. Though what I don't understand is why I can't reproduce this issue on the master branch of Nix...
Yay! I’ve opened so that we can have a proper release with the fix (the faulty commit) is a backport of (which is on master), but I had to rework it a little bit as the code had changed in the meantime. And that’s when I introduced the bug.
will a Nix 2.3.15 release be made soon enough? (before the end of the week) Or should the patch be applied on 2.3.14 until then? Given that this is a major blocker and tarnishes experience for new users, I think we should land a fix for this before the end of the week.
As far as I understand/experiment, the proposed temporal fixe downloads everything into the live folder instead of the folder: The problem is that the livecd does not have a huge space, and it tends to run out of space. Is there a way to download packages in the store to benefit from a larger space? -- EDIT -- I also tried to upgrade nix using the unstable channel (I though the bug was not present in master) and upgrade nix with , but it seems that it is not enough to allow to run flawlessly.
So... we update nix then?
I understand that it is happily fixed but what do I need to do to install a fresh nixos now? Can we have some explanation for less technical folks?
You don't have to reinstall
I got a fresh install image and updated channels but still run into this problem, that's why I asked what to do :).

Ultimately I see that I just needed to run what you suggested in initial post:
no isos have been built with the pr yet backport pr
Latest 21.05 ISOs should have all the fixes in them now.
Just waiting on to finish, then I'll unpin
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I've used 21.05 and haven't spotted this bug.
All maintained channels and ISOs should be fixed now. (or at least contain those nix updates)
It only occurs if you add new packages to your nixos configuration that don't exist in the image. If your initial install is a subset of the image, you're fine.
Yep, the issue only happens if you attempt to copy a fixed output derivation from a substituter into a chroot store. It's kind of rare but very unpleasant for people who try to do this thing that should work during installation.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there: