Installer fails

The full log is here:

and the interesting bit seems to be:

installing the boot loader...
setting up /etc...
/etc/tmpfiles.d/journal-nocow.conf:26: Failed to resolve specifier: uninitialized /etc detected, skipping
All rules containing unresolvable specifiers will be skipped.
Initializing machine ID from random generator.
Created "/boot/efi/EFI".
Created "/boot/efi/EFI/systemd".
Created "/boot/efi/EFI/BOOT".
Created "/boot/efi/loader".
Created "/boot/efi/loader/entries".
Created "/boot/efi/EFI/Linux".
Copied "/nix/store/m6qj9brj0xmigvsadsq5n86kp36cxqb5-systemd-250.4/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/systemd/systemd-bootx64.efi".
Copied "/nix/store/m6qj9brj0xmigvsadsq5n86kp36cxqb5-systemd-250.4/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/BOOT/BOOTX64.EFI".
Created /etc/machine-info with KERNEL_INSTALL_LAYOUT=bls
Random seed file /boot/efi/loader/random-seed successfully written (512 bytes).
Failed to write 'LoaderSystemToken' EFI variable: Input/output error
Traceback (most recent call last):
  File "/nix/store/x7n0hb8bsiv6308q2qh7rlwaw04r58yn-systemd-boot", line 317, in <module>
  File "/nix/store/x7n0hb8bsiv6308q2qh7rlwaw04r58yn-systemd-boot", line 243, in main
    subprocess.check_call(["/nix/store/m6qj9brj0xmigvsadsq5n86kp36cxqb5-systemd-250.4/bin/bootctl", "--path=/boot/efi"] + flags + ["install"])
  File "/nix/store/x9na3pxf7134pq7dkn1kgy9df6lf1z4v-python3-3.9.13/lib/python3.9/", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/nix/store/m6qj9brj0xmigvsadsq5n86kp36cxqb5-systemd-250.4/bin/bootctl', '--path=/boot/efi', 'install']' returned non-zero exit status 1.

2022-10-21 - 13:10:49 [6]: void Calamares::ViewManager::onInstallationFailed(const QString&, const QString&)
    Calamares will quit when the dialog closes. 
2022-10-21 - 13:10:49 [6]: QML Component (default slideshow) deactivated
2022-10-21 - 13:10:49 [6]: void Config::doNotify(bool, bool)
    Sending notification of completion: failed 

I fiddled about a bit but I’m clueless about nixos. Attempting nix-build --install-bootloader switch I got Warning: do not know how to make this configuration bootable; please enable a boot loader. although I had /boot mounted and efivars existed.

Quick google shows someone else has seen this before: Failed to set LoaderSystemToken EFI variable: Invalid argument · Issue #75457 · NixOS/nixpkgs · GitHub

Very much looks like a firmware thing indeed.

Ah, even better, from that issue, it seems you can just enable this option and it’ll magically work: boot.loader.systemd-boot.graceful.

Caveat being that those efi variables won’t be set of course, but your hardware is practically misbehaving, so it’s the best you can do.

I’m still running off the installer usb stick here. I added the option to configuration.nix and retried nix-build --install-bootloader switch. For several hours now the system has been unresponsive (even the mouse won’t move) after saying “building the system configuration”, and the usb stick’s light is still flashing. Is this normal? I’m not sure why so much stuff would depend on the bootloader or configuration.nix.

Incidentally, as for hardware misbehaving, last time I had aggro with efi I was told by Gigabyte that efi is a very vague spec which every manufacturer implements differently, so rather than expecting every box to “behave” like the one you test on, perhaps it would be better to retain MBR as a fallback.

That’s what you’ll get if you boot in mbr mode. All Linux distros behave this way these days. It’s just that you’ve chosen UEFI, so the installer will do as you ask.

Not to my knowledge, though admittedly I’ve never used the graphical installer. Things hardly take 10 minutes for me, and I have no idea why it would be writing/reading from the USB that much. Is it accidentally using the USB as a tmpfs?

Not exactly sure what you mean by “depend on”. You can’t really boot without a boot loader, or at least, you’d struggle to boot a desktop Linux without one.

As for configuration.nix, everything being defined in it (and files you can import from it) is NixOS’ raison d’être - it’s how you do declarative system configuration. Many people here - myself included - will refuse to make any changes to their systems that do not go through that file in some fashion, deliberately, so that they can keep it in git and keep track of changes over time.

Some even wipe their systems on every reboot to ensure nothing accidentally escapes: Erase your darlings: immutable infrastructure for mutable systems - Graham Christensen

You can technically escape that file a little, but for things as core as the bootloader I would not recommend it. It’d be like using debian and writing your own initramfs script.

If the mouse won’t move I’m inclined to believe you’ve gotten a kernel panic. The mouse is usually the last graphical element to fail.

Gigabyte is kinda lying then. UEFI is a fairly well defined spec. The problem is that manufacturers usually implement it kinda poorly. So Gigabyte is basically saying “everyone else sucks at it; why not us?”

1 Like

I didn’t get much further with this, but about the MBR fallback, my bios is offering MBR/EFI depending on what it finds on the boot disk. The USB image for installing Nixos doesn’t seem to have an MBR, so it only offers EFI.

About Gigabyte lying: on that occasion, their stuff worked perfectly. They were helping me to get around the idiocy of Asrock. But it’s an imperfect world, so I say, please keep MBR as a fallback.

The image is built with isohybrid on x86, which adds an MBR: nixpkgs/iso-image.nix at 7bc0c0e8a6530dca28c088e348766e366c575d49 · NixOS/nixpkgs · GitHub

If you’re not on x86 this explains it. If you are, set your motherboard into legacy mode; I’ve rarely seen the mixed mode thing actually work.

If neither works, I think that’s a bug.

To be clear, this almost certainly has nothing to do with legacy BIOS vs UEFI. Your system almost certainly kernel panicked for an unrelated reason. Setting boot.loader.systemd-boot.graceful = true; or boot.loader.efi.canTouchEfiVariables = false; would solve the error you got with UEFI.

1 Like