<abathur>
klardotsh supersandro2000 I stumbled on https://mrmacintosh.com/securetoken-documentation/ just now while reading about recent ~user features for anything that might be related to the big sur recovery issue--I wonder a little if this explains the Nix issues in some headless/vm/cloud contexts; can you see what `sysadminctl -secureTokenStatus <username>` says?
<abathur>
I found a new note in Big Sur in a very obscure place--the usage info for sysadminctl which shows up if you run the command argless--that says "*Role accounts require name starting with _ and UID in 200-400 range."
<abathur>
oh huh, it also has a new flag that is clearly for this rough purpose...
<tristan[m]>
I've packaged a mac app before that required running a service and I used an account in that uid range and starting with an _ to run the service lol
<tristan[m]>
although unintentionally because I just ripped apart another mac installer and found out what it was doing
<abathur>
I'll need another run to increase my confidence but I may have a procedure for making the users with sysadminctl that skirts the recovery problem
<dhess>
that thread title says it's about encrypting the Nix volume, but it's turned into a fairly major (and ongoing) rewrite of the installer.
<dhess>
It would drop the single-user install, in fact, so this problem would start to affect lots more people if it's not addressed before that PR is merged.
<dhess>
Unless it is somehow coincidentally fixed by changes in that PR :)
__monty__ has quit [Quit: Biab, building on a memory-poor system >.<]
<abathur>
it isn't, currently (it's my pr :P); I've been thinking it should probably have a focused issue and potentially a separate PR, but make sure anyone who can cut a release knows not to cut one with 4289 until one addressing this is also in
<abathur>
I want to avoid further bottlenecking review/testing on that by coming in late and upending how all of the user/group stuff works
<abathur>
I'll have a 2nd test run done shortly to hopefully confirm, just started the "reboot" phase of the upgrade
<dhess>
abathur: hahahahahaah
<dhess>
that was really dumb of me. I thought that PR was from thefloweringash
<dhess>
my apologies :)
rb2k has joined #nix-darwin
TFTIO has joined #nix-darwin
<abathur>
hehe, it happens
<abathur>
ok, the 2nd run did get through, and this time I let it do all 32 users instead of just 8 in case that had any impact
<abathur>
downside of this will be that it doesn't really square with how steps are sliced up in the existing poly* multi-installer
<TFTIO>
Hi all. I'm interested in moving my package management over from Homebrew to nix -- I already use NixOS on my linux machines, so I'm pretty comfortable
<TFTIO>
but I'm a little confused on how to create and use a declarative configuration for my machine
<TFTIO>
I'm happy to just start with packages, and eventually move to a broader configuration
<TFTIO>
question, what's the question, right
<TFTIO>
So I use fish, and I went to the nix-darwin page, and I ran the nix-build ... installer command, and then the darwin-installer, and it seems to complete, but then, I open a new shell, and
<TFTIO>
darwin-rebuild is nowhere to be found
TFTIO has quit [Remote host closed the connection]
__monty__ has joined #nix-darwin
<mocker>
Any ideas for getting this set w/ nix-darwin?
<mocker>
well this isn't fun. did system update and failed into recovery.
<mocker>
Reading scroll back says rebooting may help, *cross-fingers*
<abathur>
yes
<andi->
has anyone investigated why ctags/neovim isn't building natively on M1 boxes? It is basically the package that prevents me from using my home-manager config :D (neovim is kinda at the center of all my workflows)
<mocker>
The options (even the "com.apple" ones) have to be in that module to be set
<thefloweringash>
Killed 9 is normally a bad code signature
<andi->
thefloweringash: when does code signing happen? I think neovim might be executing something it has just built the second before that.
<thefloweringash>
On link, strip and install_name_tool
<andi->
hm, /tmp/nix-build-neovim-unwrapped-0.4.4.drv-0/source/build/bin/nvim is what is being executed, doing it manually returns 137
<andi->
and codesign --verify --verbose looks like it has some entitlement
rb2k has quit [Ping timeout: 258 seconds]
rb2k has joined #nix-darwin
philr has quit [Ping timeout: 272 seconds]
<klardotsh>
abathur: I'll spin up a new mac1.metal soon and let you know what that output is
<klardotsh>
abathur: fwiw while catalina on EC2 gave me nightmares (and forced me to write pretty long docs to explain all the edge cases to coworkers), the coworker code reviewing the work installed on his Catalina box with *none* of the nightmares. installer script from files.t-travis, nix-darwin installer, restart terminals, "lorri shell" and off to the races
<klardotsh>
so there's some box specific weirdness going on
<klardotsh>
sadly though he upgraded to Big Sur last night and hosed his whole machine. for now he trashed the apfs volume for the nix store to be able to reinstall OS and get sprint work done, but I'd be curious to hear about any fixes that wouldn't have involved nuking the nix store
rb2k has quit [Ping timeout: 272 seconds]
rb2k has joined #nix-darwin
<abathur>
klardotsh: ah, yeah
<dhess>
klardotsh: I assume it booted into recovery mode. This seems to be happening to people with multi-user Nix installs. I have 4 machines where that happens. In every case, I can just run Disk Utility from recovery mode, First Aid on the system volume, reboot, and the upgrade process resumes and completes normally.
<dhess>
Each time, Recovery Mode claims I'll have to reinstall, but I've never needed to.
<klardotsh>
ooh! interesting. I screenshotted this and forwarded it along, though I think he already got things back to stable
<abathur>
klardotsh: my wild guess on these VM/EC2 issues is that there's some part of either the setup assistant process, or having/using the GUI, that is basically an unknown dependency for being able to run the installer/daemon; it doesn't get seen normally since mortals are using systems directly with normal setup but then is prone to drop when the toolchain is short-circuiting those
<abathur>
It'd be nice to track it down and at least understand/document it, but I wasn't able to reproduce it despite a few hours hoop-jumping to get a VM set up locally
<abathur>
so I guess step 1 is a reproduction case, maybe we need to make an issue titled for whatever the first sign/problem is, and see if we can eventually attract a reliable test case
<abathur>
I think I have more good news on the big-sur/recovery front; I worked back from how sysadminctl sets up the accounts and tried doing it roughly the same way, but without actually using completely new commands, and it looks like I was also able to update cleanly from there
<abathur>
that, if true, should greatly simplify updating the installer; it'd be mostly changing some variables and arguing about the new values instead of having to refactor the poly* install script with version detection to handle versions of macOS that don't have the new flag and such