Hello, I experienced power loss and after that bootloader tries to find LUKS with different UUID than before. Booting into previous generations help and it looks up correct UUID. Hardware config looks fine, it has correct UUID. Any ideas for solution?
Which bootloader? Can share screenshot?
Hello, I experienced power loss and after that bootloader tries to find LUKS with different UUID than before. Booting into previous generations help and it looks up correct UUID. Hardware config looks fine, it has correct UUID. Any ideas for solution?
Since you can still boot into your system and your hardware config looks fine, what happens if you just rebuild your system for a new generation?
Nothing changes, but I noticed that when I do nixos-rebuild list-generations
, unfunctional rebuilds have NixOS version 24.05.3999.c42fcfbdfeae
and kernel version 6.6.46
, maybe that’s the cause?
That screenshot is showing initrd failing, not the boot loader. Can you share your hardware-configuration.nix and the output of lsblk -o NAME,UUID,PARTUUID,LABEL,PARTLABEL
?
lsblk
NAME UUID PARTUUID LABEL PARTLABEL
sda
└─sda1 0C2487C52487AFEE 000bdb70-01 VPIČIDATA
sdb
├─sdb1 751df161-59a0-4a83-912b-c6fff9d125d7 Microsoft reserved partition
└─sdb2 7A30B12230B0E673 859ff7aa-e1aa-42a6-8c71-df9688d6d9e9 DATA Basic data partition
sdc
sdd
sde
sdf
sr0
nvme0n1
├─nvme0n1p1 0C38-1072 a7069390-2b35-49df-925e-7d67003442a2
├─nvme0n1p2 d2bc5788-5fab-4d2e-9cac-0674e89323de 4a2224bb-a562-49b3-9f4c-ec55e5bc53e5
│ └─root 29ce3bfd-c5cd-4f87-b395-ac29d1461051
└─nvme0n1p3 A81EC91D1EC8E602 be366c5b-c6c5-4f2b-8534-1c31c4bc4e6b
hardware-configuration.nix
# 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, modulesPath, ... }:
{
imports =
[ (modulesPath + "/installer/scan/not-detected.nix")
];
boot.initrd.availableKernelModules = [ "nvme" "xhci_pci" "ahci" "usbhid" "usb_storage" "sd_mod" "sr_mod" ];
boot.initrd.kernelModules = [ ];
boot.kernelModules = [ "kvm-amd" ];
boot.extraModulePackages = [ ];
fileSystems."/" =
{ device = "/dev/disk/by-uuid/29ce3bfd-c5cd-4f87-b395-ac29d1461051";
fsType = "ext4";
};
boot.initrd.luks.devices."root".device = "/dev/disk/by-uuid/d2bc5788-5fab-4d2e-9cac-0674e89323de";
fileSystems."/boot" =
{ device = "systemd-1";
fsType = "autofs";
};
swapDevices = [ ];
# Enables DHCP on each ethernet and wireless interface. In case of scripted networking
# (the default) this is the recommended approach. When using systemd-networkd it's
# still possible to use this option, but it's recommended to use it in conjunction
# with explicit per-interface declarations with `networking.interfaces.<interface>.useDHCP`.
networking.useDHCP = lib.mkDefault true;
# networking.interfaces.docker0.useDHCP = lib.mkDefault true;
# networking.interfaces.enp6s0.useDHCP = lib.mkDefault true;
nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux";
hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;
}
Well this is definitely not correct. You must have regenerated hardware-configuration.nix
when the FS wasn’t mounted and systemd-gpt-auto-generator
had created this automount unit, which nixos-generate-config
doesn’t handle correctly. The result would be that your /boot
files aren’t getting updated correctly.
I’m not sure why this would cause the exact problem you showed in that screenshot, but you should manually mount the correct disk to /boot
, regen hardware-configuration.nix
, and rebuild.
Okay, I fixed the problem by running nixos-install
from USB installation.