-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
install: configure and bootstrap synthetic.conf on darwin #3212
Conversation
Wait, this is viable? From following #2925, I thought the consensus was that nixpkgs currently has impurities in it that preclude using a (symlink to a) non- |
There's a big difference between changing If we avoid this on the hydra infrastructure that build the official caches (at least for now) I think it won't be a problem anybody runs into in practice. |
I am a bit concerned that what I download from Hydra wouldn't match what I build locally, e.g. someone already said llvm (or clang?) seems to do a realpath on the build location and will embed the symlink destination. As long as Another potential benefit of the volume approach that's been mentioned is the fact that we can make it case-sensitive. |
Ahh, gotcha. I think I understand now. And as @lilyball says, this would mean that packages built with a "real" store path of |
Long term this wouldn't be a problem. I'm more concerned about the complexity of managing a separate volume and what could change/break there in the future. |
cc @edolstra I tested this and it works, it would be great to have 2.3.2 release out once it's reviewed and merged. |
So worst case, if the official macOS builders stay on pre-10.15 for awhile and keep building packages for a physical In any case, I think this should be |
Are the Hydra macOS builders guaranteed to run on the OS that we use as the minimum macOS target? If we ever run a 10.15 Hydra macOS builder while we still support pre-10.15, that means binary caches for packages that "see through" the symlink will then break on the older OSes. |
I like this solution a lot. However, since I experimented with a symlinked store before, we may need to extend the purity checks in the Unfortunately, I do not remember what I was building back then. So this is more of a warning than a call for action right now. |
Aside from the obvious problems regarding purity, it's worth noting here that I've so far encountered a few inconsistencies in nix from trying to switch to a symlink'd store path:
|
256b22e
to
c39c829
Compare
@mroi Things like that I what I was most afraid of, would be great if you had an example. |
I honestly do not remember. Sorry. If I find the time, I will try some things I usually build myself. |
Note that we'll also need to fix #2407 in order to support macos + multi-user mode. EDIT: already done in d4e51aa#diff-3f9ecc4aa9722ed5597a741e4cb91d3e |
c39c829
to
7543121
Compare
@@ -176,11 +180,15 @@ let | |||
--absolute-names \ | |||
--hard-dereference \ | |||
--transform "s,$TMPDIR/install,$dir/install," \ | |||
--transform "s,$TMPDIR/create-darwin-volume.sh,$dir/create-darwin-volume.sh," \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why only this file ends up in the wrong place.
Looks good besides a few small things. I think it would be good to get this in a Nix release pretty soon as we lose lots of potential users without a well-documented Catalina installer. Tried on a fresh macOS using the following steps:
|
break | ||
;; | ||
esac | ||
i=$((i+1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be let i+=1
} | ||
|
||
apfs_volumes_for() { | ||
disk=$1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps local
break | ||
fi | ||
case "$name" in | ||
[Nn]ix*) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're using bash this could be written as
if [[ "$name" == [Nn]ix* ]]; then
echo "$name"
break
fi
echo " 1. Remove the entry from fstab using 'sudo vifs'" | ||
echo " 2. Destroy the data volume using 'diskutil apfs deleteVolume'" | ||
echo " 3. Delete /etc/synthetic.conf" | ||
echo "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole thing could be done as a heredoc
cat >&2 <<EOF
------------------------------------------------------------------
| This installer will create a volume for the nix store and |
| configure it to mount at /nix. Follow these steps to uninstall. |
------------------------------------------------------------------
1. Remove the entry from fstab using 'sudo vifs'
2. Destroy the data volume using 'diskutil apfs deleteVolume'
3. Delete /etc/synthetic.conf
EOF
@lilyball Given that |
3832259
to
97c6595
Compare
The default login shell for users on macOS 10.15 changed from bash to zsh. So while generally nonstandard we need to configure it to make nix function out of the box on macOS.
This should handle installation scenarios we can handle with anything resembling confidence. Goal is approximating the existing setup--not enforcing a best-practice... Approaches (+ installer-handled, - manual) and configs each covers: + no change needed; /nix OK on boot volume: All pre-Catalina (regardless of T2 or FileVault use) + create new unencrypted volume: Catalina, pre-T2, no FileVault + create new encrypted-at-rest volume: Catalina, pre-T2, FileVault Catalina, T2, no FileVault - require user to pre-create encrypted volume Catalina, T2, FileVault
f44919c
to
2b0a81d
Compare
|
I'm going to merge this, given that people have been reporting for months that it works (and now that documentation has been written) it seems like not much will improve until we get this live. |
So either I'm missing something or the instructions in the manual definitely don't work. It complains about asking for the flag about --daemon | --no-daemon and I cannot seem to supply either argument. It isn't threading the flags through to the installer correctly. What's going on here? |
@ProofOfKeags How are you building/obtaining the install script? What exact command are you using? |
EDIT: after digging it seems apparent that whatever install script I'm fetching does not even include the option for the --darwin... I gather this hasn't been pushed out to the main host? |
A new version of Nix hasn't been released yet. Edit: I don't know exactly what the release/deploy cycle for Nix looks like, but (AFAIK) if you watch the repo for a new release, the command you quoted should work at approximately that time :) |
Until it's released, my macOS system bootstrap has been doing roughly (I'm adapting it for you--I last ran it before any of this work was merged...) this:
(create-darwin-volume.sh is what the |
@ProofOfKeags Aside from this mishap: You may be one of the first to try following the manual update from scratch--any feedback? Do you have questions it didn't answer? |
The guide seemed fairly straight forward, I think. But given that the first command didn't work and I didn't bother trying to go through the rest since it'll work when it is released, I can't say for sure whether the instructions for the rest of it will work. I actually have half a mind right now to partition my mac again and just use NixOS raw, because MacOS seems to be increasingly hostile towards developers. |
@abathur just for confirmation I was successfully able to remove my single user-install and reinstall a multi-user installation on Catalina + T2 + Filevault earlier today running those same commands |
@abathur I can confirm that I could successfully set up nix on Catalina (with T2 chip) with the commands
|
Fixes #2925.
Here's some preliminary documentation for the apfs volume creation section.
Updated to create an apfs volume instead of using the symlink approach. This works on a clean install but I expect there are other corner cases that are not covered. More testing is probably required.
Using a symlink instead of a separate volume is the most straightforward approach which relies less on darwin specific tools. However it does have some disadvantages, especially if this has to be changed in the future. Also the new location should be avoided for official infrastructure (at least for a while) so installation using an apfs volume should probably also be implemented somewhere.From my testing it looks like
apfs.util
works properly now, unless this breaks again a reboot can be bypassed for both mountpoints and symlinks.