In reply to @skano:matrix.org
my zshrc.backup-before-nix file contains nix

In reply to @abathur:matrix.org
Matthew Kenigsberg cole-h I did get https://github.com/NixOS/nix/pull/11075 updated with the approach we discussed Wednesday, if either of you get a chance to give it a shake

dscl . read /Users/_nixbld1 (through 4) gives eDSRecordNotFound, but 5+ are fine (as we'd expect)

Mostly just repeating context from the PR thread into this discussion:

Here's where the assumption that they exist but lack a UID comes from:

https://github.com/NixOS/nix/issues/10948#issuecomment-2201254269

Since it seems like that was either mistaken or maybe Apple's shifted the behavior (perhaps properly deleting the users is their "fix"?), fixing installs that have already been upgraded to sequoia is probably going to be a lot less fun.

Approaches I can imagine so far:

1. Update migration script to detect some-nixbld-users-but-not-nixbld1 and either

   • Tell these people they'd be better off reinstalling and point to the instructions to do so. Downside of user frustration around repeating builds (but most people who need to reinstall currently seem to suffer this without too much complaining), but it wouldn't entail much more novel work here.
   • Port full user/group creation logic into the migration script, add a routine to delete existing users/groups to simplify the task, fall back on those in this condition. Downside of this is that full logic for the user creation routine (implemented in create_build_user_for_core() in scripts/install-multi-user.sh is scattered over at least 19 functions (maybe more, I haven't walked down the tree) plus some variables, so it'll take a little effort to cleanly extract and leave us with a copy to maintain.

2. Look at adding a new top-level routine to the multi-user installer itself that can delete existing users/groups (new code) and re-create them (can hopefully re-use existing code), add a flag to install-nix-from-closure to trigger that option. Downsides: needing a more extensive installer update/check cycle to make sure we aren't breaking stuff and that the new deletion routine works, making people do a full installer download to fix this, harder to test and re-use (especially before a proper release) since it isn't a standalone script. Open question as to whether the option should be generic like recreate-build-users (implying some time to make sure this works on linux as well), or more explicitly scoped to save effort.

   I'm not sure if it'd still make sense to have the standalone migration script if its utility were enabling people who learn about it before taking the upgrade to save a little time with the quicker operation of just updating UIDs. If we did retain the separate script there's a risk of confusion around when to run it so it'd probably need to do 1 above but point people at the user-recreation installer flag instead of uninstall instructions.

3. I'm probably not serious about it due to a variety of issues with getting it implemented and rolled out, but at least in theory Nix itself could probably be able to do some detection and self-healing around broken/missing build users. Downside is probably that we'd still be looking at suggesting uninstall/reinstall to anyone who didn't intentionally or coincidentally end up with a Nix with this capability before they take the upgrade?

In reply to @abathur:matrix.org
cole-hMatthew Kenigsberg force-pushed to take a swing at this. Untested :)