building the system configuration...
Failed to read EFI boot order: Invalid argument
Traceback (most recent call last):
File "/nix/store/jzs1byj1ss0h3y76n23q1cxggi4rv13w-systemd-boot/bin/systemd-boot", line 452, in <module>
main()
~~~~^^
File "/nix/store/jzs1byj1ss0h3y76n23q1cxggi4rv13w-systemd-boot/bin/systemd-boot", line 435, in main
install_bootloader(args)
~~~~~~~~~~~~~~~~~~^^^^^^
File "/nix/store/jzs1byj1ss0h3y76n23q1cxggi4rv13w-systemd-boot/bin/systemd-boot", line 339, in install_bootloader
installed_out = run(
~~~^
[f"{SYSTEMD}/bin/bootctl", f"--esp-path={EFI_SYS_MOUNT_POINT}", "status"],
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
stdout=subprocess.PIPE,
^^^^^^^^^^^^^^^^^^^^^^^
).stdout
^
File "/nix/store/jzs1byj1ss0h3y76n23q1cxggi4rv13w-systemd-boot/bin/systemd-boot", line 58, in run
return subprocess.run(cmd, check=True, text=True, stdout=stdout)
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/qwb5ygz9k8gs5ql9bpxbrsrv12r1icgm-python3-3.13.12/lib/python3.13/subprocess.py", line 577, in run
raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/nix/store/y2rzx7s3kr3v95rsrl2141s8vaa4mkjf-systemd-258.5/bin/bootctl', '--esp-path=/boot', 'status']' returned non-zero exit status 1.
activating the configuration...
reloading user units for brian...
restarting sysinit-reactivation.target
the following new units were started: NetworkManager-dispatcher.service
Done. The new configuration is ⏎
It would appear to work despite the error. But if I leave it like that, it looks like important boot files get garbage collected and the system becomes unbootable.
I find it hard to believe that I am the only one having this issue?
Should I replace systemd-boot with grub again? That seemed to be fine. I don’t understand why this would be required though.
That’s nicely weird. Can you run the bootctl command manually and reproduce the error? I’d hope it would emit some useful error messages, but if not strace-ing it might yield some clues.
But have updated and retested several times since that was posted, and it hasn’t helped.
At present “sudo bootctl --esp-path /boot status” works fine.
Probably should retest nix deploy sometime, but don’t want to have to reboot the computer again right now, and as above if I don’t reboot the computer and fix I risk having an unbootable system. Will try again tomorrow.
LLM suggested patching nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py; but so far that has not helped, and I have reverted.
Have you tested the exact same bootctl binary? I.e. /nix/store/y2rzx7s3kr3v95rsrl2141s8vaa4mkjf/bin/bootctl, and after you switch into the broken config? An strace really would be helpful, if you can’t reproduce it we’ll have to patch the activation script.
It’s a different error message but it also seems like a very similar failure mode. Looks like probably this error code, which is similar in class to ones we’ve seen before from systemd, which is also similar to the issues linked in the other discourse thread. I think it’s safe to say it’s the same basic category of issue: efivarfs is doing something weird after hibernation and it’s causing bootctl to bug out.
That’s pretty surprising. systemd-boot-builder.py shouldn’t ever cause existing entries to become unbootable, even when there’s a bootctl failure. This part might be a NixOS bug.
Well, if my hypothesis is correct, you are indeed experiencing an unusual behavior of efivarfs, which could be due to a hardware-specific bug that no one else may have dealt with yet.
That’s the idea, but rather than just “by hand” - assuming you can’t reproduce it the first time around - use the full binary path, just in case it’s a bug with a specific version.
@ElvishJerricco is likely correct and this is an efivarfs thing, but it’d be nice to confirm what bootctl is up to when it bugs out. That’d hopefully give more of a clue as to what to do to prevent it bugging out.
Sounds more like a hard/firmware issue, like @ElvishJerricco suggests. Maybe you didn’t fully reboot but hibernate before previous attempts, or you booted into Windows or something.
If you see it again, try to get an strace on it.
I’d also suggest a firmware update, those can sometimes help with this kind of thing.
