darwin installer: remove the file before installing new one

[domenkozar]

Otherwise results into:

cp: /Library/LaunchDaemons/org.nixos.nix-daemon.plist and /nix/var/nix/profiles/default/Library/LaunchDaemons/org.nixos.nix-daemon.plist are identical (not copied).

[domenkozar]

Not sure this fixes it: /Library/LaunchDaemons/org.nixos.nix-daemon.plist: service already loaded

[domenkozar]

Although I'd argue that should be a separate check at installation

[LnL7]

If we want to support this it's probably best to also ensure that whatever has been loaded by launchd is also removed first.

sudo launchctl remove org.nixos.nix-daemon

[domenkozar]

I think the script should be idempotent, @grahamc came quite far in #1551

[blast-hardcheese]

seems 0644 is needed

[blast-hardcheese]

Compare:

brick:~ blast$ launchctl stop org.nixos.nix-daemon && launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist
brick:~ blast$ sudo install -m 0664 /nix/var/nix/profiles/default/Library/LaunchDaemons/org.nixos.nix-daemon.plist /Library/LaunchDaemons/org.nixos.nix-daemon.plist
brick:~ blast$ launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist && launchctl start org.nixos.nix-daemon
/Library/LaunchDaemons/org.nixos.nix-daemon.plist: Path had bad ownership/permissions

with

brick:~ blast$ launchctl stop org.nixos.nix-daemon && launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist
brick:~ blast$ sudo install -m 0644 /nix/var/nix/profiles/default/Library/LaunchDaemons/org.nixos.nix-daemon.plist /Library/LaunchDaemons/org.nixos.nix-daemon.plist
brick:~ blast$ launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist && launchctl start org.nixos.nix-daemon

[stale]

I marked this as stale due to inactivity. → More info

[fricklerhandwerk]

Still relevant.

[Ericson2314]

I rebased this and changed the mode as @blast-hardcheese accepted. I also made it symbolic because that is much more readable/maintainable.

[Ericson2314]

I don't really think there is a good way to test this between CI and just....deploying to the wild --- at least I don't know of a good manual test plan.

I did some manual copying to my home directory with cp and install. I could not reproduce the original issue --- I thought cp -f was supposed to be idempotent?! --- but I could confirm that the new thing is at least idempotent too.

The bottom line is that install is...meant to be used in installers. Being explicit about the mode and not trusting unpacking is also good. Trying to be idempotent is always laudable. The theory is sound. I say we finally merge this tiny one line change, and see what happens. Users will let us know if something unpredictable goes wrong :).

[abathur]

I'm unsure why it would take so long to manifest as user reports, but it doesn't look like the mode part of this change works, and I'm starting to suspect it's causing some people to turn up with Bootstrap failed: 5: Input/output error errors during service init on reinstalls.

$ touch inst1
$ /usr/bin/install -m -rw-r--r-- inst1 inst2
$ ls -la inst*
-rw-r--r-- 1 abathur _lpoperator      0 Feb 12 12:19 inst1
---------- 1 abathur _lpoperator      0 Feb 12 12:21 inst2

FWIW I see the same behavior with the nix-installed coreutils implementation of install.

User reports I've spotted so far:

• later on in nix profile [verb] failing on MacOS 14 with permission error #9702
• Installer fails on macOS Ventura 13.6.3 #9969
• macOS installation: Could not find service "org.nixos.darwin-store" in domain for system #9978

Won't be able to start on anything myself until this evening, but I imagine this will cause enough ongoing grief until all of the wild installs with these perms age out that it's worth getting a point release together, and maybe an issue with a lucid explanation and a clear workaround to pin.

If someone happens to pull together a PR with installer tests configured, I have a spare x86_64-darwin system that I can use to confirm it.