NixOS config flake conversion breaks bootloader

Hi I tried migrating my configuration to flakes. It successfully installed once, but when I tried to do a full system reinstall using it. It crashed out to an emergency TTY after running sudo nixos-reboot switch --flake .#vortex , and then on rebooting it says that my phase 1 bootloader is missing. I’m honestly not even sure how to start troubleshooting this, so any help would be appreciated. Also I’m not sure what info will be usefull so if you need screen shots of specific error messages, please just let me know.

Link to my config repo: GitHub - Iron-Shark/Technonomicon: Repository for system configuration files

Side note: NixOS really lived up to one of it’s selling points through this. I had fallback.configuration.nix in my repo, that was a copy of my pre-flakes conversion configuration. So once I started having issues, I just dropped that in instead during the install, and was back to a working system. Makes it so much easier to learn and experiment. :grinning:

What says this? Can you share what this looks like?

I’m am going to describe the full process that leads me to this, along with posting the pictures.

  1. New installation from usb. No Desktop, unfree allowed
  2. Reboot into the new system
  3. log in, connect to wifi, and nix-env -i git vim
  4. mkdir Projects && cd Projects
  5. git clone && cd Technonomicon
  6. sudo nixos-rebuild switch --flake .#vortex
    This builds, but ends up stuck on this

If I allow it to sit for a while. It eventually boots me to this screen.

C-d just brings me back to this same prompt. Rebooting from either the root shell option, or just normally turning the system on results in this prompt at start up.

which after a little while is followed by.

I wonder if it has something to do with your file systems? It’s certainly unusual to have a /boot/efi file system but not a /boot file system, and it’s even fairly encouraged to only have the /boot one. I don’t see how that could cause the issues you’re seeing, but it’s the only anomalous thing I’m seeing here.

In the linked repository, there are 2 machines, each of them with their own hardware configuration.

On a quick glance, the used UUIDs for each / seem to be the same, is this indeed correct?

No, the stuff for voyager is just a copy of vortex acting as a place holder. So that I know where to put everything when I set up that machines configuration.

The posted screenshots definitely appear to support my suspicion, please check the UUID used to mount /. Or even better: mount by label/partlabel. Much less errorprone and can be controlled.

So I am not sure exactly what you are asking for. So if this is not it. Sorry.
I took a screen shot of my currently running non-flakes based system, next to the one in my repo with labels at the top: Current system is on the left, flake is on the right.

The UUIDs for both the device and file system are differnt. Does this mean that as part of a fresh install I need to move the hardware config file generated by that new installation into the flake. Rather than just having one for that machine as part of the repository?

Take a look at /dev/disk/by-uuid, there will be one or more links to block devices in /dev.

Use the UUID that indeed points at your root filesystem and use that in your hardware configuration.

Alternatively use an appropriate entry from /dev/disk/by-label or /dev/disk/by-partlabel

So I got it working. Basically I assumed that since I am not making any changes to the computer hardware between installations, Eg. changing out storage drives, or adding a gpu, ect. The contents of hadware-configuration.nix file would be static. Its not, the UUIDs inside the file change.

The solution was to copy the newly generated hardware file (created by the installer) into the existing flake.

Thank you @NobbZ for pointing me in the right direction, and sorry if this should have been obvious.

The UUID of a filesystem is static.

Though once you created a new partition or used mkfs.ext4 or whatever, a new filesystem gets created, with a new UUID.

This is why I always suggest to use label or partlabel, as those are under user control and therefore can be the same between different runs of “formatting” the partition.

1 Like