Changed motherboard, how to fix bootloader now?

Help
1

I only changed my motherboard and cpu. I can’t see boot option for nixos on my motherboard at all. I have 2 ssd, one windows other is nixos and their bootloader is different. Windows is able to boot when I changed my motherboard out of the box but I can’t see any uefi bios option on nixos. I was remember I was installed nixos with gnome iso and enabled systemd-boot on configuration.nix

  # Bootloader.
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

I didn’t found a solution for nixos but in this one:

Summary

(Why am I unable to boot Ubuntu after motherboard change? - Ask Ubuntu)

users says because of initramfs but I have no idea how can I solve this on nixos. It would be great if you guys now how to do it or how to use ubuntu solution on nixos.

I was using 23.11 and upgraded new version 24.05. I am thinking about the reinstalling from scratch but I prefer not to.

2

Maybe the boot order got messed up. From a live ISO, you can use efibootmgr to find out the current order:

nix-shell -p efibootmgr --run "efibootmgr -v"

It should give you BootOrder: YYYY,XXXX,ZZZZ and a description of each entry, for example BootXXXX* Linux Boot Manager and BootYYYY* Windows Boot Manager.

If the bootloader for linux does not come first (left has most priority), you need to change it with:

nix-shell -p efibootmgr --run "sudo efibootmgr -o XXXX,YYYY,ZZZZ"

When doing this, I recommend you copy the BootOrder entries from the first command and just re-order them.

3 
[nixos@nixos:~]$ nix-shell -p efibootmgr --run "efibootmgr -v"
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0002
Boot0002* Windows Boot Manager	HD(1,GPT,f56268f5-aeb0-406a-9d32-bfbb1e29cb05,0x800,0x100000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038
      dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 f5 68 62 f5 b0 ae 6a 40 9d 32 bf bb 1e 29 cb 05 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 49 00 43 00 52 00 4f 00 53 00 4f 00 4600 61 00 38 00 36 00 32 00 63 00 2d 00 35 00 63 00 64 00 64 00 2d 00 34 00 65 00 37 00 30 9 00 35 00 7d 00 00 00 66 00 01 00 00 00 10 00 00 00 04 00 00 00 7f ff 04 00
Boot0003* Hard Drive	BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)0000474f00004e4fc7000000010000008b00480079007000650072005800200046007500720079002000330044002000340038003000470042000000050109000200000000010416008b12e85cec2cf040837280640e3dc85802007fff040002010c00d041030a0000000001010600020101010600010003120a000100ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce63000350032003000420036003200370032003800310034003100450046003700200020002000200000007fff04000000424f00004e4fd7000000010000008700530061006d00730075006e00670020005300530044
      dp: 05 01 09 00 02 00 00 00 00 / 01 04 16 00 8b 12 e8 5c ec 2c f0 40 83 72 80 64 0e 3d c8 58 02 00 / 7f ff 04 00
    data: 00 00 47 4f 00 00 4e 4f c7 00 00 00 01 00 00 00 8b 00 48 00 79 00 70 00 65 00 72 00 58 00 20 00 46 00 75 00 72 00 79 00 20 00 33 00 44 00 20 00 34 00 38 00 30 00 47 00 42 00 00 00 05 01 09 00 02 00 00 00 00 01 04 14 34 00 ef 47 64 2d c9 3b a0 41 ac 19 4d 51 d0 1b 4c e6 53 00 34 00 45 00 55 00 4e 00 4d 00 30 00 54 00 32 00 32 00 30 00 30 00 34 00 35 00 4d 00 00 00 7f ff 04 00 00 00 42 4f

I wasn’t able to do last one. I tried 0003, Boot0003 but says invalid.

configuration.nix (only some important ones)

  boot = {
    loader = {
      systemd-boot = {
      enable = true;
      #timeout = 5;
      #defaultKernelOptions = [ "quiet" ];
      };
      efi = {
        canTouchEfiVariables = true;
        #systemPartition = "/boot";
      };
    };

    # reno cubic enabled: 83-89down 18-19up
    # after bbr enabled: 89-93down 18-20up
    kernelModules = ["tcp_bbr"]; # Enable BBR congestion control algorithm.
    kernel.sysctl = {
      "net.ipv4.tcp_congestion_control" = "bbr";
      "net.core.default_qdisc" = "fq";
      "net.core.wmem_max" = 104857000; # 100Mib
      "net.core.rmem_max" = 104857000; # 100Mib
      "net.ipv4.tcp_rmem" = "4096 87380 104857000"; # 4Kib 87Kib 100Mib
      "net.ipv4.tcp_wmem" = "4096 87380 104857000"; # 4Kib 87Kib 100Mib
    };

 {
    use-xdg-base-directories = true;
    builders-use-substitutes = true;
      
    substituters = [
      "https://cache.nixos.org/"
      #"https://nix-community.cachix.org"
    ];  
    trusted-public-keys = [ 
      "cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY="
      #"nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs="
    ];

    max-substitution-jobs = 20;
  };
1 Like
4

Boot into the ISO, mount your partitions and chroot into your system using nixos-enter. Then run

NIXOS_INSTALL_BOOTLOADER=1  /run/current-system/bin/switch-to-configuration boot

That should reinstall the bootloader.

3 Likes
5

i’m getting a replacement motherboard in the next couple weeks… thanks I’m advance? :grin:

1 Like
6

Even though there are no errors when running such a command, that doesn’t work, unfortunately, because it doesn’t set the necessary EFI variables.

There’s a much simpler solution:

  1. Boot a live ISO
  2. Mount the ESP to say, /boot
  3. Run bootctl --path=/boot install
  4. Reorder the entries using efibootmgr to put the NixOS-managed bootloader up first
    • Currently this last step doesn’t work, because the version of efibootmgr in nixpkgs is broken, however, this should be fixed if the relevant PR is merged (EDIT: PR’s merged now.)
1 Like
7

It was a solution for me when I did it that time, and I used NixOS until then, never experiencing any errors due to boot issues. For future usage, are you insistent on reinstalling the bootloader in your way, or is it okay to use the working command from @hexa?

8

Yes, it does. That’s part of what NIXOS_INSTALL_BOOTLOADER=1 does.

9

Well, empirically, it’s inadequate somehow. I just had a motherboard firmware update after which bootctl worked and NIXOS_INSTALL_BOOTLOADER=1 did not.

10

That’s not really possible, because NIXOS_INSTALL_BOOTLOADER=1 literally causes it to run bootctl install. So either you made a mistake or there’s some obscure bug.

11

For all I know, bootctl doesn’t work in nixos-enter. I’m just reporting my observations for the sake of the next person who runs into this, not trying to debug why nixos’ cursed perl scripts may or may not work.

(And by the way, I happened to find out that envvar from reading the code in the first place, not from this thread.)

12

Well, empirically, it does, because I’ve done it a few dozen times by now. I also know why it works. The nixos-enter program creates a mount namespace and rbind mounts the API filesystems, including everything under /sys which includes the efivarfs. The systemd-boot-builder would fail at the bootctl install step if this wasn’t working.

Seriously, I’m fairly sure you simply made a mistake, such as running NIXOS_INSTALL_BOOTLOADER=1 sudo /run/current-system/bin/switch-to-configuration boot, which wouldn’t work because the sudo would wipe the environment variable.

13

Seriously, I didn’t. I know that sudo clears envvars by default, as documented by my very answers on this forum that explain that to other users.

Here’s the exact conversation I had with someone else:

2025-03-02_17-51
2025-03-02_17-511890×608 127 KB

That’s about all the proof I’ll bother to provide that I am in fact not a complete idiot.

14

That’s very strange, and is definitely a bug that I’ve never seen after doing this and helping others with it many times. If you have the ability to reproduce that on a system, it would be useful to file an issue so we can fix it.

15

Also, I’m not calling you “a complete idiot.” I’m trying to understand something that doesn’t make sense to me given how I know these things work. I’m sorry if I came off as offensive. The advice you gave about bootctl install is not as generally applicable, as it doesn’t generate boot entries, so it would be better if we understood why the more comprehensive solution didn’t work for you. The only explanation I’ve thought of so far is that you made a mistake, which is not a criticism; we all make mistakes. If you didn’t, then we’ve got a bug on our hands that doesn’t yet make sense to me and seemed rather unlikely before.

Another possibility is that you didn’t have boot.loader.efi.canTouchEfiVariables set, since it defaults to false, which causes systemd-boot-builder.py to pass --no-variables to bootctl. But then I’m not sure how the system would have booted before the firmware update, unless the update caused it to stop respecting the BOOTX64.EFI fallback loader… I dunno, this is confusing.

16

Yes, my suggested solution is only applicable when the bootloader’s state itself is correct, and the only change needed is to get the firmware to recognise said bootloader. (Although I’d question how that generation would be the “current system” if it was never activated and didn’t generate the corresponding boot entry.)

The default might be false but n-g-c sets it to true when booting under EFI:

As does the graphical installer:

So any relatively recent config would have this set to true, as I do:

image
image737×255 27.4 KB

17

Yea. A lot of people handroll their configs though so I had to ask. Again, I’m not trying to tell you that you don’t know what you’re doing. As a member of the NixOS teams for systemd and the installer, my responsibility is to fix these things when people have issues like you did. Based on how all the relevant code is written and how it’s expected to work, I can’t find an edge case to explain what happened in your experience. So I’d really like to find what I’m missing, if you can think of any details that would help.

18

I kinda understand how happy this guy was :sweat_smile: