Switch to UID 351+ and GID 350 on macOS

emilazy commented

2024-09-10 15:43:02 +00:00

Member

macOS Sequoia will release on Monday and break the majority of existing installations as well as all new ones using the current UIDs/GID. The ecosystem is standardizing on UIDs 351+ for the build users and GID 350 for new installations on macOS. Current installations can keep the old GID but must have their UIDs migrated for Sequoia compatibility.

See https://github.com/NixOS/nix/pull/10919 and https://github.com/NixOS/nix/pull/11075 for where the values were settled upon (with some help from an Apple devrel) and a shell migration script was implemented (which should work for Lix users at a pinch).

This has already been implemented upstream in Determinate Systems’ installer and they are working on a command to repair existing installations; see https://github.com/DeterminateSystems/nix-installer/issues/1115. Hopefully you can backport their change ASAP so that new installations work after Sequoia’s release, and the repair command is meant to ship Thursday or earlier. I’m not sure if you’re in a position to signal users that their installation will break before it does, but I’m currently implementing that in nix-darwin. (It would be helpful to know if there is a canonical way to detect whether an installation was installed with lix-installer, esp. to disambiguate it from the Determinate Systems installer.)

This would fix #18, but I wanted to track the more concrete thing here especially since it’s high‐priority.

macOS Sequoia will release on Monday and break the majority of existing installations as well as all new ones using the current UIDs/GID. The ecosystem is standardizing on UIDs 351+ for the build users and GID 350 for new installations on macOS. Current installations can keep the old GID but must have their UIDs migrated for Sequoia compatibility. See https://github.com/NixOS/nix/pull/10919 and https://github.com/NixOS/nix/pull/11075 for where the values were settled upon (with some help from an Apple devrel) and a shell migration script was implemented (which should work for Lix users at a pinch). This has already been implemented upstream in Determinate Systems’ installer and they are working on a command to repair existing installations; see https://github.com/DeterminateSystems/nix-installer/issues/1115. Hopefully you can backport their change ASAP so that new installations work after Sequoia’s release, and the repair command is meant to ship Thursday or earlier. I’m not sure if you’re in a position to signal users that their installation will break before it does, but I’m currently implementing that in nix-darwin. (It would be helpful to know if there is a canonical way to detect whether an installation was installed with `lix-installer`, esp. to disambiguate it from the Determinate Systems installer.) This would fix https://git.lix.systems/lix-project/lix-installer/issues/18, but I wanted to track the more concrete thing here especially since it’s high‐priority.

emilazy commented

2024-09-10 16:28:13 +00:00

Author

Member

Note also that existing installs are fine to remain on GID 30000. The move to GID 350 at the same time was to solve a cosmetic problem with the Nix build user group showing up in System Settings, and for consistency with the UIDs. The upstream migration script does not change the GID because of worries about interfering with existing file ownership in /nix. I don’t know what Determinate Systems’ plans are regarding group migration, but I would expect the same.

Note also that existing installs are fine to remain on GID 30000. The move to GID 350 at the same time was to solve a cosmetic problem with the Nix build user group showing up in System Settings, and for consistency with the UIDs. The upstream migration script does not change the GID because of worries about interfering with existing file ownership in `/nix`. I don’t know what Determinate Systems’ plans are regarding group migration, but I would expect the same.

jade commented

2024-09-11 05:37:58 +00:00

Owner

blegh. thank you for reporting this.

lix-bot commented

2024-09-11 05:48:32 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1906 ("[Nix#11075] Add script to migrate macOS 15 Sequoia nixbld UIDs")
commit message in cl/1907 ("[DetSys#1123] Synchronize macOS UIDs and GIDs with upstream scripts to prepare for Sequoia")
commit message in cl/1913 ("store: add a hint on how to fix Lix installs broken by macOS Sequoia")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1906](https://gerrit.lix.systems/c/lix/+/1906) ("[Nix#11075] Add script to migrate macOS 15 Sequoia nixbld UIDs") * commit message in [cl/1907](https://gerrit.lix.systems/c/lix-installer/+/1907) ("[DetSys#1123] Synchronize macOS UIDs and GIDs with upstream scripts to prepare for Sequoia") * commit message in [cl/1913](https://gerrit.lix.systems/c/lix/+/1913) ("store: add a hint on how to fix Lix installs broken by macOS Sequoia")

emilazy commented

2024-09-12 16:08:16 +00:00

Author

Member

https://github.com/DeterminateSystems/nix-installer/pull/1143 has now been merged; @jade I think backporting that would probably be a better approach than backporting the Nix shell script.

Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer?

https://github.com/DeterminateSystems/nix-installer/pull/1143 has now been merged; @jade I think backporting that would probably be a better approach than backporting the Nix shell script. Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer?

jade commented

2024-09-12 20:23:58 +00:00

Owner

check for /nix/lix-installer

emilazy commented

2024-09-12 20:48:01 +00:00

Author

Member

Hmm, I thought that https://gerrit.lix.systems/c/lix-installer/+/1502 hadn’t yet landed so it was still installing as /nix/nix-installer?

 #[tracing::instrument(level = "debug")]
 async fn copy_self_to_nix_dir() -> Result<(), std::io::Error> {
     let path = std::env::current_exe()?;
     tokio::fs::copy(path, "/nix/nix-installer").await?;
     tokio::fs::set_permissions("/nix/nix-installer", PermissionsExt::from_mode(0o0755)).await?;
     Ok(())
 }

Hmm, I thought that https://gerrit.lix.systems/c/lix-installer/+/1502 hadn’t yet landed so it was still installing as `/nix/nix-installer`? https://git.lix.systems/lix-project/lix-installer/src/commit/962d7bf7452998697eb6a5fecac11891a1d430ac/src/cli/subcommand/install.rs#L390-L396

jade commented

2024-09-12 22:03:59 +00:00

Owner

fuck i feel so burned out

lilyball commented

2024-09-13 00:16:51 +00:00

Member

Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer?

If the change is backported, assuming the Lix installer will be able to repair installations originally made with the DetSys installer, then I'd recommend checking whether nix.package is nix or lix as I expect there are a lot of folk like me who did a DetSys installation originally and then subsequently adopted Lix.

> Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer? If the change is backported, assuming the Lix installer will be able to repair installations originally made with the DetSys installer, then I'd recommend checking whether `nix.package` is nix or lix as I expect there are a lot of folk like me who did a DetSys installation originally and then subsequently adopted Lix.

emilazy commented

2024-09-13 00:42:10 +00:00

Author

Member

I’m working on backporting the repair command.