Hi,
I have a question about automounting /nix from /etc/fstab on macOS.
By default there is a noauto option which prevents /nix from being mounted during the boot process.
I want to launch some services at the boot time without the hassle of adding /bin/wait4path ... to every service .plist. I am not using any Disk / Volume encryption, so I don’t really understand the reason to rely on launchd to mount /nix in my case.
Are there any potential problems / issues with removing noauto option and disabling
launchd mounter /Library/LaunchDaemons/org.nixos.darwin-store.plist ?
The installer does it the same way whether you’re using filevault or not to simplify the install base where we can, and because automount was happening too late for gui apps restoring on boot for fv users.
AFAIK what you’re describing should work fine in your case.
1 Like
One asterisk here is that macOS/launchd preserve disabled services, so I’d at least try to remember to re-enable it before uninstalling Nix.
(We occasionally hear from people who disable one or both nix-related service at some point and and later try to reinstall Nix and then get cryptic failures during the steps to set up those services.)
Thank you, @abathur. The setup I described in OP works in practice, but I am not sure if volumes in fstab are guaranteed to be mounted before launchd starts to launch other services. I wonder if there’s a better way to solve this problem, especially when services have dependencies. In this case I would have to implement some part of the functionality of systemd, which I would like to avoid.
As far as I’m aware, we haven’t found a way that certainly gets us out of the race (but I also haven’t personally tested this stuff extensively after Catalina, so I can’t speak to whether newer macOS versions have improved this).
We don’t technically need the mounting service to mount an encrypted volume, it’s just that when we leave it up to automount it seems to not actually get decrypted before GUI apps can start restoring (a straightforward case that can break is a restoring terminal with a nix-supplied shell and profile script).
I interpret that to mean automounting itself is a race. I (personally) have never seen us lose the race against GUI/restore on a non-filevault Nix install that predates the mounting service, so it could also be the case that the first round of automounts blocks boot and only unblocks after everything gets a try?
I haven’t hammered as hard on building some other system-level LaunchDaemon that depends on the volume. Observing a real break there would confirm the hypothesis that it’s just a race (even if it would be otherwise disappointing).
We might also be able to confirm one way or another if Apple happens to have released this specific code at some point. I don’t recall for sure whether I looked into that or not. It’s been a few years now since we did most of the testing around this.
If you find a better way on either front, I imagine we’re interested.
Perhaps we could build around this limitation with some abstractions in nix-darwin.
1 Like