So, resume= sets the device the kernel is supposed to resume from, and resume_offset= sets the offset in the device where the swap header is located. You’re asking the kernel to read the block device /home and resume from ~90MB into that block device. You also don’t need to set resume since that’s done by boot.resumeDevice.
/home is not a block device, and an offset of ~90MB into a directory makes no sense. It’s unsurprising this doesn’t work.
Use the block device that /home is on, and point the kernel at the offset of the swapfile in there.
You can get the offset of the file with filefrag -v /home/swapfile - you’re looking for the physical_offset.
So in other words:
{
boot = {
# Ideally, replace this with `/dev/disk/by-uuid/<UUID>` so the device
# doesn't randomly change; use `lsblk -o +UUID` to find it
resumeDevice = "/dev/nvme0n1p2";
kernelParams = [ "resume_offset=<physical offset of the file>" ];
};
}
This is assuming you’re using e.g. ext4, if you use other file systems, ideally just don’t use a swapfile. I know you are, but I want to repeat that because it’s a major data destruction risk at least on btrfs.
Also, as an aside, putting a file like this in /home is very weird, use /swap, or maybe a subdirectory of /var.
Of course, this is also quite unreproducible. NixOS will create swapfiles that don’t exist automatically for you, but getting the offset in the filesystem can only be done at runtime, so you’ll never get a fully reproducible system this way.
Really, the more I think about this the more I disrecommend using swap files. They’re anything but noob-friendly, inherently cause reproducibility issues, technically less performant due to the possibility of fragmentation, and an inherent data destruction risk with certain file systems. The only benefit is that they’re easy to resize, but that inherently causes the very fragmentation that makes them imperformant, so you should never actually do that (and nobody tells you this…). Plus, this is not the early 2000s, resizing filesystems is quite possible. If this is something you find yourself worried about just use LVM volumes.
