Nixpkgs: NixOS 18.03 minimal fails fresh install (systemd-boot-builder)

[slimey]

Issue description

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 Failed to create EFI Boot variable entry: No such file or directory:

# nixos-install
building the configuration in /mnt/etc/nixos/configuration.nix...
[168 built, 274 copied (1188.0MiB), 23.9 MiB DL]
copying channel...
installing the boot loader...
setting up /etc...
Initializing machine ID from random generator.
Created "/boot/EFI".
Created "/boot/EFI/systemd".
Created "/boot/EFI/BOOT".
Created "/boot/loader".
Created "/boot/loader/entries".
Copied "/nix/store/dzrd8yxh9r1bwisphg3z47dxrxlgskv1-systemd-237/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/nix/store/dzrd8yxh9r1bwisphg3z47dxrxlgskv1-systemd-237/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
Failed to create EFI Boot variable entry: No such file or directory
Traceback (most recent call last):
  File "/nix/store/71qjm4rjlxzz7z4dsxd8dndj9dlyil38-systemd-boot-builder.py", line 210, in <module>
    main()
  File "/nix/store/71qjm4rjlxzz7z4dsxd8dndj9dlyil38-systemd-boot-builder.py", line 185, in main
    subprocess.check_call(["/nix/store/dzrd8yxh9r1bwisphg3z47dxrxlgskv1-systemd-237/bin/bootctl", "--path=/boot", "install"])
  File "/nix/store/lp7x6ziq5b2zihgad0i8a28xxvz5vnrr-python3-3.6.4/lib/python3.6/subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/nix/store/dzrd8yxh9r1bwisphg3z47dxrxlgskv1-systemd-237/bin/bootctl', '--path=/boot', 'install']' returned non-zero exit status 1.

Running under strace, there is a possible match at

openat(AT_FDCWD, "/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_WRONLY|O_CREAT|O_NOCTTY|O_CLOEXEC, 0644) = -1 ENOENT (No such file or directory)

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 here.

Steps to reproduce

I tried to follow the vanilla NixOS installation instructions as closely as possible.

Technical details

[This is the installation CD system]

• system: "x86_64-linux"
• host os: Linux 4.14.32, NixOS, 18.03.131792.becbe4dbe16 (Impala)
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.0
• channels(root): "nixos-18.03.131792.becbe4dbe16"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

In case relevant, the hardware-configuration.nix contents are:

# Do not modify this file!  It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations.  Please make changes
# to /etc/nixos/configuration.nix instead.
{ config, lib, pkgs, ... }:

{
  imports = [ ];

  boot.initrd.availableKernelModules = [ "sd_mod" "sr_mod" "hv_storvsc" ];
  boot.kernelModules = [ ];
  boot.extraModulePackages = [ ];

  fileSystems."/" =
    { device = "/dev/disk/by-uuid/992d6869-7bf5-4c4d-a25b-5eca354b731c";
      fsType = "ext4";
    };

  fileSystems."/boot" =
    { device = "/dev/disk/by-uuid/57D8-AB48";
      fsType = "vfat";
    };

  swapDevices =
    [ { device = "/dev/disk/by-uuid/dbdbddff-d580-42dd-b553-b205b2e56ff9"; }
    ];

  nix.maxJobs = lib.mkDefault 4;
  services.xserver.videoDrivers = [ "fbdev" ];
}

[bcarrell]

Having the same issue right now.

[anselmio]

Getting the same using nixos-graphical-18.03.131800.ac3437aa061-x86_64-linux.iso for a fresh installation attempt. Identical installation steps with nixos-graphical-17.09.3205.12512f25e9e-x86_64-linux.iso succeeds.

[bcarrell]

Confirmed that nixos-minimal-17.09.3205.12512f25e9e-x86_64-linux.iso also succeeds in my case.

---

• nixos-minimal-17.09.3205.12512f25e9e-x86_64-linux.iso :heavy_check_mark:
• nixos-minimal-18.09pre133640.ea145b68a01-x86_64-linux.iso :x:
• nixos-minimal-18.03.131802.4b4bbce199d-x86_64-linux.iso :x:

[Redcroft]

I'm having the same issue on an Acer ES1-132

[smashedtoatoms]

Yep, here too on an XPS 13 9370

[LSLeary]

I had the same issue. My workaround was to temporarily set

boot.loader.efi.canTouchEfiVariables = false;

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.

efibootmgr -c -d /dev/sdb -p 9 -L "SystemD" -l "\efi\systemd\systemd-bootx64.efi"

(on my system the EFI boot partition is /dev/sdb9)

There were also *.efi files generated in \efi\nixos, but I didn't try any since it booted with this.

[steven-a-wilson]

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.

[andrewchambers]

is anyone actively working on this? what does severity blocker signify?

[smashedtoatoms]

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.

[adamtulinius]

Also seeing this when installing on vmware, but with custom install media built from the nixos-18.03channel as of today (c0c5571ec1a33a5109c122b8821eb15c36cbb1ec). No problems with 17.09. EFI is certainly enabled on the host.

[ghost]

I run into the exact same problem while trying to install NixOS 18.03 into VMware.

[nenad]

I got the same behaviour when I tried to install NixOS 18.03 on Dell XPS 13 (9360).

[forgemo]

Same issue when tying a fresh install of nixos-minimal-18.03.132021.c0c5571ec1a-x86_64-linux.iso on VirtualBox. "EFI" option in virtual machine system settings is enabled. I followed the install instructions as closely as possible.

[joseph-long]

Cannot perform a clean install on Lenovo X1 Yoga 2018.

[basvandijk]

I got the same issue when installing NixOS-18.03 (ad222f3c1433e77b6d8483fd93ea7e7357ad0424) on a recent Intel NUC.

[samueldr]

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, this workaround should work. Once installed, the canTouchEfiVariables option can be put back to the defaults (removed from your configuration) as the issue only affects the installation environment.

[joseph-long]

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 added did not appear as a startup option.

[samueldr]

Alternatively, boot.loader.grub.efiInstallAsRemovable can be used with grub,

If you turn this feature on, GRUB will install itself in a special location within efiSysMountPoint (namely EFI/boot/boot$arch.efi) which the firmwares are hardcoded to try first, regardless of NVRAM EFI variables.

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 rEFInd at /EFI/boot/bootx64.efi 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

• https://hydra.nixos.org/build/73334588

This build is the iso built in the same evaluation that is probably going to be the next channel update. (Only one test is left to run AFAIK.)

EDIT^2: There was a failure (chromium) known issue, may be a bit longer to see a fixed iso... (Even the core devs cannot cheat the build pipeline to ship a fixed iso.) The linked iso should be safe (AFAIK) to use.

---

I do remind any users in the future that using a random iso image from the past to fix a similar issue may not be a productive use of your time. A similar issue may come from an entirely different cause. :)

[Wolfereign]

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.

[slimey]

Confirmed (what Wolfereign said) - thanks!

[andrewchambers]

I think this issue was automatically closed by the github merge bot, but shouldn't have been.

[samueldr]

4 days ago, it shouldn't have been closed; github doesn't know about nixos channels.

The current iso image on nixos.org is made from commit b50443b5c4a, which is after e932b5be26, and includes the fix.

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 you have a fresh image from nixos.org and it fails with this issue or a similar one, please open an issue and/or contact the community.

This specific issue should be fixed.

[vcunat]

If I look correctly, the ISO on web has been b50443b for over thirty hours now, and that commit does contain e932b5be2. 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 :-)

[Wolfereign]

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.

[adamtulinius]

This appear to be broken again. It did work for some time, but install media made from today (and a few days back) fail in the same way as in the top post.

Edit: Ignore me. We did something silly with efibootmgr to wipe EFI entries during install, which weirdly enough triggers exactly this error.