When I try to install and boot NixOS, I get the following error:
<<< NixOS Stage 1 >>>
loading module btrfs...
loading module dm_mod...
running udev...
Starting systemd-udevd version 254.3
Passphrase for /dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2:
Verifying passphrase for /dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2... - successs
starting device mapper and LVM...
Scanning for Btrfs filesystems
registered: /dev/mapper/crypted
mounting /dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2 on /...
mount: mounting /dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2 on /mnt-root/ failed: invalid argument
An error occurred in stage 1 of the boot process, which must mount the
root filesystem on `/mnt-root' and then start stage 2. Press one
of the following keys:
r) to reboot immediately
*) to ignore the error and continue
I think that invalid mount argument must be due to something wrong in the NixOS generated symlinked /etc/fstab, which looks like this:
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2 / btrfs x-initrd.mount,subvol=root,compress=zstd,noatime 0 0
# other fs'es here ...
Note that on a live USB, I can mount the system by doing:
$ cryptsetup open /dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2 crypted --key-file $key_file
$ mount /dev/mapper/crypted /mnt-root/ -o compress=zstd -o noatime -o subvol=root -o X-mount.mkdir
$ ls /mnt-root
etc bin var tmp srv other_dirs...
My hardware-configuration.nix looks like:
fileSystems = {
"/" = {
device = "/dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2";
fsType = "btrfs";
options = [ "subvol=root" "compress=zstd" "noatime" ];
};
# other fs'es here...
}
boot = {
initrd.luks.devices.crypted.device = "/dev/disk/by-id/nvme-WD_BLACK_SN770_500GB224448800320-part2";
# other options here ...
};
# other options here ...
So the output that you provide here looks like ${disk}should have been replaced with something but actually hasn’t. But maybe I am just confused.
Other than that, what would ${disk}-part2 refer to? On my system disks are called something like nvme0n1p2 for nvme drive 0, namespace 1, partition 2. Now I mount them by uuid, but since you want to do it in this way, there should be something akin to my designation showing up on your end.
Because they were potentially confusing, I removed the references to ${disk}, which were originally just to save typing when posting this question (not actually in the output of initrd). When using by-id, the disk is /dev/disk/by-id/nvme-... and the second GPT partition (where BTRFS is installed) is /dev/disk/by-id/nvme-...-part2. Does that make sense?
So on my installation the naming scheme for disks and paritions has no -part2 in it. If you want to mount the second partition on the first nvme disk in your system it most likely will be like this: nvme0n1p2.
Can you maybe provide the output of ls -la /dev/disk/by-id on your system?
Edit: I might have been a bit confused. Still the output would be helpful I guess
Anyway, I switched /dev/disk/by-id/nvme-WDBLACK_SN770_500GB_224448800320-part2 to /dev/disk/by-uuid/big-long-uuid, which are both themselves symlinks to /dev/nvme0n1p2. Still same error.
Yes, that question has gotten more interesting. I am not really sure right now what the error might be here. Other than not using uuids your config does not look much different from mine. Maybe someone else has another idea.
btrfs should work without any extra tricks, but i’ve never tried luks, therefore i suspect it’s something to do with it. For example - it’s trying to mount device, but is it actually trying to mount the mapped decrypted device?
i wonder also that doc say config for luks goes in boot.initrd.luks, not in boot.luks - can it affect?
hi! So i’ve tried to repeat the basic steps of setting up luks on a VM, and indeed, uuids for actual disc and whatever luks decrypts are different, here’s my example: ll /dev/disk/by-uuid
(vda - is the virtual disc that is being encrypted, and the last line is the thing that luks creates when decrypting that device)
see, mapper one points to the same device
That was exactly the problem. boot.initrd.luks.device."crypted".device needed to point to /dev/nvme0np2 but fileSystems."/home".device needed to point to /dev/dm-0.
I have to admit, I’m having a hard time understanding how folks solved this problem.
I happen to have a very similar situation to this problem. The problem occurred when I had to force restart on a system that was in the middle of running sudo nixos-rebuild switch --upgrade. Here’s what my situation looks like:
<<< NixOS Stage 1 >>>
loading module btrfs...
loading module dm_mod...
running udev...
Starting systemd-udevd version 254.6
Passphrase for /dev/disk/by--uuid/b90c2010-a53c-4f76-9802-95fdde248601 to appear. . . . -successs
Verifying passphrase for /dev/disk/by--uuid/b90c2010-a53c-4f76-9802-95fdde248601... - successs
starting device mapper and LVM...
Scanning for Btrfs filesystems
registered: /dev/mapper/luks-/b90c2010-a53c-4f76-9802-95fdde248601
mounting /dev/disk/by--uuid/b90c2010-a53c-4f76-9802-95fdde248601 on /...
[ 8.956086] BTRFS error(device dm-0_: openk_ctree failed
mount: mounting /dev/disk/by--uuid/b90c2010-a53c-4f76-9802-95fdde248601 on /mnt-root/ failed: Input/output error
An error occurred in stage 1 of the boot process, which must mount the
root filesystem on `/mnt-root' and then start stage 2. Press one
of the following keys:
r) to reboot immediately
*) to ignore the error and continue
When I opt for “ignore the error and continue,” I’m notified the following:
Continuing...
BusyBox v.136.1 () multi-call binary.
Usage: switch_root [-c CONSOLE_DEV] NEW_ROOT NEW_INIT [ARGS]
Free initramfs and switch to another root fs:
chroot to NEW_ROOT, delete all in /, move NEW_ROOT TO /.
execute NEW-INIT. PID must be 1. NEW_ROOT must be a mountpoint.
Would anyone be so kind to break the solution down for me?
That error is not indicative of any one problem. It’s the generic “oops something died” message for any failure during stage 1. So there isn’t one solution to break down for you. You’ll have to provide more of the log of what went wrong. But given that you mentioned a forced restart, I’m willing to guess your file system got damaged.
