Change:
exit 126 fi <del> mkdir -m 0755 -p "$mountPoint/dev" </del> <ins> mkdir -m 0755 -p "$mountPoint/dev" "$mountPoint/sys" </ins> mount --rbind /dev "$mountPoint/dev" <ins> mount --rbind /sys "$mountPoint/sys" </ins> # Run the activation script. Set $LOCALE_ARCHIVE to supress some Perl locale warnings. LOCALE_ARCHIVE=$system/sw/lib/locale/locale-archive chroot "$mountPoint" "$system/activate" >&2 || true

Discussion:
Installing Nixos from the 18.03 minimal installation DVD iso, for a fresh 64-bit Hyper-V vm target system, is failing for me at : Running under strace, there is a possible match at but this was from a quick grep from a lot of content, so might well be a red herring. That path is present in the host (CD-booted) system. Full trace . I tried to follow the vanilla NixOS installation instructions as closely as possible. [This is the installation CD system] system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: In case relevant, the hardware- contents are:
Having the same issue right now.
Getting the same using for a fresh installation attempt. Identical installation steps with succeeds.
Confirmed that also succeeds in my case. :heavycheckmark: :x: :x:
I'm having the same issue on an Acer ES1-132
Yep, here too on an XPS 13 9370
I had the same issue. My workaround was to temporarily set after which the install would succeed but not write the boot-listing efivar. Then I manually created that efivar with efibootmgr. I imagine the command would have worked from the installation media, but I'm not sure since I ran it in Debian. (on my system the EFI boot partition is /dev/sdb9) There were also *.efi files generated in efinixos, but I didn't try any since it booted with this.
I saw this as well, on an AsRock Z77 Extreme4. LSLeary's workaround was fine for me since I prefer to boot via rEFInd anyway. I was able to manually touch or cp another boot entry to the destination (per strace) without any error, so it doesn't seem that the firmware is preventing the creation of the variable.
is anyone actively working on this? what does severity blocker signify?
I know this ticket is for a fresh install, but I installed 17.09 and upgrade 18.03 and it worked fine in case anyone needs a workaround.
Also seeing this when installing on vmware, but with custom install media built from the nixos-18.03channel as of today (). No problems with 17.09. EFI is certainly enabled on the host.

I run into the exact same problem while trying to install NixOS 18.03 into VMware.
I got the same behaviour when I tried to install NixOS 18.03 on Dell XPS 13 (9360).
Same issue when tying a fresh install of nixos-minimal-18.03..-x86_64- on VirtualBox. "EFI" option in virtual machine system settings is enabled. I followed the install instructions as closely as possible.
Cannot perform a clean install on Lenovo X1 Yoga 2018.
I got the same issue when installing NixOS-18.03 () on a recent Intel NUC.
A fix has been pushed to the master and 18.03 branches. It will take some time to reach the channel, and for a new ISO to be generated using the fix, but this specific issue should be fixed soon for new installs. In the meantime, should work. Once installed, the option can be put back to the defaults (removed from your configuration) as the issue only affects the installation environment.
For the record, I was unable to boot using the aforelinked efibootmgr workaround on a 2018 Lenovo X1 Yoga. I had a pre-existing Linux boot entry, which I removed, but the new entry that I did not appear as a startup option.
Alternatively,  can be used with grub, This will put the bootloader in the default fallback location. While it is documented as "hardcoded to try first", I'm not sure this is right. It will, though, try to boot that specific location when no other option is possible. As a final alternative, adding at in the ESP (the fallback location) can help; rEFInd will scan for existing EFI programs on the ESP partitions, which would allow selecting systemd-boot. Though, all of this assumes that the installation process finished. EDIT: For anyone reading this in the (hopefully) few hours left until the channel bumps and the iso updates on the website This build is the iso built in the same evaluation that *
Sorry to drag this from the dead but the website has not updated to the new Isos. the build mentioned by samueldr is complete and the iso there solved this issue on hyper-v for me.
Confirmed (what Wolfereign said) - thanks!

I think this issue was automatically closed by the github merge bot, but shouldn't have been.
4 days ago, it shouldn't have been closed; github doesn't know about nixos channels. The current iso image on is made from commit , which is after , and . Simply put, the 18.03 iso do contain the needed fix for this specific issue. The iso image on the website was updated somewhere between ~24h ago (when the channel advanced) and a couple hours ago when I checked whether the iso image changed. I have also, just in case, verified that it does not reproduce the fixed issue. I'm using this post to add this note:
If I look correctly, the ISO on web has been for over thirty hours now, and that commit does contain . I wonder... can you be more specific? What do you mean by "website has not updated"? EDIT: oh, github didn't show me the last posts when I was writing this :-)
The website is updated now. When I checked at the time of my post the isos on the website (official download links) had not been updated.
Edit: Ignore me. We did something silly with efibootmgr to wipe EFI entries during install, which weirdly enough triggers exactly this error.