macOS: (re)install failure

[platy]

Describe the bug

I wanted to try out Nix again, the last time I tried it was several years ago and since I had no /nix directory I assumed I had uninstalled it already. The installer pointed out that I already had rc backups in /etc, I checked and didn't have any nix stuff in therc files so I removed the backups and ran the installer again.

This time the installer got pretty far, but failed, last bit of log output below.

~~> Setting up the default profile
warning: unknown setting 'signed-binary-caches'
installing 'nix-2.4'
building '/nix/store/0z4wmgsva2bv18ai7wz1gg311h8j32nv-user-environment.drv'...
warning: unknown setting 'signed-binary-caches'
installing 'nss-cacert-3.66'
building '/nix/store/sfq4nhk3my358wizgsylmqpgjbcq08x6-user-environment.drv'...
warning: unknown setting 'signed-binary-caches'
unpacking channels...
warning: unknown setting 'signed-binary-caches'

~~> Setting up the nix-daemon LaunchDaemon
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).

---- oh no! --------------------------------------------------------------------
Jeeze, something went wrong. If you can take all the output and open
an issue, we'd love to fix the problem so nobody else has this issue.

:(

...

Looking here at issues, I've noticed #4531 and it looks a lot like an issue I've been having with macOS upgrades, I've always managed to get passed it just by rebooting and trying again and didn't figure out what was causing it.

So now I've got a failed install of Nix from today, and I'm not sure whether I should use the fix script from that issue.

% nix-env -qa
error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted

I'm not sure how I should approach this.

Thanks

[abathur]

A full uninstall should get you back on track.

I don't think the fix in #4531 will help the issue here, but we should make sure none of the users that cause this problem are left--if they are it'll affect step 6 in the uninstall process.

You can check for nixbld users with dscl . list '/Users' | grep nixbld and note whether the names start with underscores, no underscores, or if you have a set of both.

• if all of them start with an underscore, you can follow step 6 unmodified
• if you have both sets, run step 6 once as-is, and then add for i in $(seq 1 32); do sudo dscl . -delete /Users/nixbld$i; done (the same second command, but to remove the users with no leading underscore)
• if you only have the underscore set, run for i in $(seq 1 32); do sudo dscl . -delete /Users/nixbld$i; done instead of the second command in step 6

I believe this outline of the process is up-to-date: https://gist.github.com/toonn/94a38643d8fa5c9e06100cdfa81ba163#uninstalling

[abathur]

Regarding the issue itself: I think the user fell into a gap in the installer's logic for when to print information about uninstalling (only when nix-env is already on PATH, currently).

nix/scripts/install-multi-user.sh

Lines 379 to 386 in eff48e8

	validate_starting_assumptions() {
	if type nix-env 2> /dev/null >&2; then
	warning <<EOF
	Nix already appears to be installed. This installer may run into issues.
	If an error occurs, try manually uninstalling, then rerunning this script.
	$(uninstall_directions)
	EOF

My personal (biased?) thinking is that cases like this are better handled by the ~curing practices developed in create-darwin-volume than by detect-abort-instruct. I left some breadcrumbs to this effect:

nix/scripts/install-multi-user.sh

Lines 841 to 846 in eff48e8

	cure_artifacts
	# TODO: there's a tension between cure and validate. I moved the
	# the sudo/root check out of validate to the head of this func.
	# Cure is *intended* to subsume the validate-and-abort approach,
	# so it may eventually obsolete it.
	validate_starting_assumptions

[platy]

@abathur - Thanks, uninstalling and reinstalling worked!
I did the uninstall from https://gist.github.com/toonn/94a38643d8fa5c9e06100cdfa81ba163#uninstalling .

I had the 32 _nixbld users and 4 nixbld users.

The only other difference I found was with the launch daemons, I didn't have org.nixos.activate-system.plist and org.nixos.nix-daemon.plist wasn't running, but I did have org.nixos.darwin-store.plist, which was running so I unloaded and deleted that as well (I guessed it was an older version)

After that, I ran a new install and all is well! Thanks!

I guess I'll see whenever I upgrade to Monterey if this fixes my issue with crashes during upgrade.

[abathur]

Thanks, uninstalling and reinstalling worked!

Glad that got you on track :)

The only other difference I found was with the launch daemons, I didn't have org.nixos.activate-system.plist

This should be fine. I think it would only be present if you were also using nix-darwin before.

I guess I'll see whenever I upgrade to Monterey if this fixes my issue with crashes during upgrade.

The main thing to look out for, if you use zsh, is that macOS has been regularly rewriting /etc/zshrc during updates. If so, nix won't be on PATH after the update, and you'll need to re-add the Nix lines.

[stale]

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