Backstory:
I’m installing NixOS for the first time, I created my ESP with cfdisk, which was a FAT32 partition mounted at /mnt/boot. When executing nixos-install, it failed, and I realized that it was just a regular FAT32 partition, so I reformatted it to the type “EFI System”, which changed the UUID from XXXX_XXXX to a new one, YYYY_YYYY. I hadn’t done much to configuration.nix, frankly, I hadn’t even created a user or configured networking. I re‑executed nixos-install with success and rebooted my system without knowing that I would be struggling a bit afterwards.
Now:
When booting into my new system, a systemd mount unit has been trying to mount /dev/disk/by-uuid/XXXX_XXXX and dropped me into emergency mode. It obviously wouldn’t find it, as there is no longer a partition with that UUID. It should have been replaced withYYYY_YYYY, but I suppose that the first time I executed nixos-install, it had kept that UUID, which is weird. I confirmed that by checking the contents of /etc/fstab and /etc/nixos/hardware-configuration.nix, where they kept the old UUID.
Anyway, I tried to resolve that by replacing the old UUID with the new one in /etc/nixos/hardware-configuration.nix and executed nixos-rebuild switch, but it outputs Failed to connect to system scope bus via local transport: No such file or directory. I assumed it needed D-Bus to rebuild, so I started its service, but it made me wait for a minute and dropped me back into emergency mode.
So I’m stumbling with this cyclic dependency: nixos-rebuild → needs D-Bus running → needs the correct UUID device → the correct UUID device needs the rebuild to apply changes
The easiest way I thought of was to manually edit /etc/fstab, but it was a read‑only file (makes sense after all).
I know I could just redo the installation, as it’s only a fresh installation of NixOS with nothing inside it, but I also wondered how I could fix this issue if it ever happened on a more established system.
You might be able to run the system with the added kernel parameter systemd.mask=boot.mount or systemd.mask=boot-efi.mount depending on where you put the mountpoint in question.
You might also be able to mask the mount unit like this
I tried adding the kernel parameters first, but this tells me that the option “systemd.mask” does not exist.
Plus, would it even have worked in the first place? I mean it would’ve still fallen back to the DBus problem.
So I tried the second method, but it tells me that the unit name /boot is neither a valid invocation ID nor unit name. (while it clearly exists)
I also tried doing it with /dev/disk/by-uuid/XXXX_XXXX but it prints the same error.
And wouldn’t it have been weird to change things imperatively? Unless if systemd is actually an exception to the declarative paradigm?
That doesn’t sound right. It sounds like maybe you tried setting that as a NixOS option in your configuration instead of adding a kernel parameter in your boot menu.
You were misinformed; try systemctl mask --runtime boot.mount (or boot-efi.mount or whatever the mount unit is that’s causing you trouble).
That command only changes things temporarily; the change goes away on the next reboot. Same for temporary kernel parameters added via the boot menu.
Oh I read it too quickly, I thought I had to do it on configuration.nix.
But now it works by adding it as a kernel parameter in GRUB.
I then mounted /dev/sda1 to /boot, the first attempt of the rebuild gave me an error saying that it was masked, but the second attempt worked for some reason.
I also tried doing the second method, which has now created a symlink, but I had yet to restart dbus, and for some reason when I try to do that it hangs my entire system and the only option I have is to restart the PC.
nixos-install was not thing choosing what the UUID should be; that’s just in the hardware-configuration.nix generated by nixos-generate-config, which nixos-install doesn’t update. Rebuilding / running nixos-install again will just continue using whatever UUID is in hardware-configuration.nix already.
This happens because switch is for reconfiguring the live services, which doesn’t work when you’ve gone into emergency mode and the system isn’t really live. The thing you needed was nixos-rebuild boot, which just builds the config and makes it bootable.
No, that was correct. systemd.mask=/boot works fine, since for certain things (including cmdline options that take unit names), systemd automatically converts values starting with / to corresponding .device or .mount units depending on if the path starts with /dev/.
I encourage you to try it with mask specifically. systemctl status / works, but systemctl mask / won’t. (Unless this was recently changed; I tested on systemd 258.3.)
Well, that’s a different thing. The systemctl mask CLI and the systemd.mask= boot param are not the same exact thing. It is a little weird that systemctl mask doesn’t accept the same /boot syntax (though FWIW in this case that would end up giving you a different error about boot.mount being a generated unit that can’t be masked at runtime), but the systemd.mask= boot param does take /boot syntax (and it does work because in that case the mask is the unit that was generated). And yes, I tried it before commenting, though I did also just now try it again with 258 to make sure.
I was responding to a (now edited) claim that systemctl mask --runtime /boot would work, in that excerpt you quoted. Glad you agree that it doesn’t. I think you and I may have gotten our wires crossed when you wrote
in which I now figure that ‘cmdline’ refers to the kernel command line, but which I initially read as referring to the systemctl command line, because that was the subject of that snippet of conversation. But I see you never actually engaged with the systemctl command line at all until I explicitly brought it up, so… no actual disagreement here, it seems.