rb2k has quit [Read error: Connection reset by peer]
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nix-darwin
rb2k_ has quit [Ping timeout: 258 seconds]
rb2k has joined #nix-darwin
rb2k has quit [Ping timeout: 264 seconds]
rb2k has joined #nix-darwin
rb2k has quit [Remote host closed the connection]
rb2k has joined #nix-darwin
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nix-darwin
contrapumpkin has joined #nix-darwin
copumpkin has quit [Killed (rothfuss.freenode.net (Nickname regained by services))]
contrapumpkin is now known as copumpkin
disasm has quit [Ping timeout: 276 seconds]
disasm has joined #nix-darwin
rb2k has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<angerman>
so if I run nix-shell shell.nix -i bash --pure, I won't get any of the PATH, and other env variables set?
rb2k has joined #nix-darwin
rb2k has quit [Client Quit]
ehamberg has quit [Read error: Connection reset by peer]
hamishmack has quit [Read error: Connection reset by peer]
hamishmack has joined #nix-darwin
ehamberg has joined #nix-darwin
<abathur>
not entirely true :)
<abathur>
also I think -i may be only for shebangs
mog has quit [Ping timeout: 246 seconds]
<thefloweringash>
andi-: my coworker has nvim running on m1, I think he bumped the sources to nightly 0.5.0 and disabled python2
<abathur>
oof
<abathur>
I'm trying the update to 11.3 beta without applying the nixbld user patch, and this is nightmarish
<abathur>
it seems like maybe it has failed into some worse ~reset kind of recovery; it made me log in with my apple account and then showed me all of the users on the system, including the nixbld ones, and roughly told me that unless I had the password for an admin account I had to reset all of their passwords one by one (but it never prompted me for a password to the admin account)
<abathur>
took pictures of those screens, then rebooted without doing anything to see if it'll still eventually boot like the previous updates
mog- has joined #nix-darwin
<abathur>
heh, it did still boot to a normal login afterwards
eraserhd has joined #nix-darwin
eraserhd3 has quit [Ping timeout: 256 seconds]
<abathur>
ok, I've updated #4351 and #4352; way past pumpkin time for me
<{^_^}>
https://github.com/NixOS/nix/issues/4531 (by abathur, 1 day ago, open): macOS Big Sur updates w/ multi-user Nix present "booted to Recovery" because "an error occurred migrating user data"
rb2k_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rb2k has joined #nix-darwin
rb2k has quit [Read error: Connection reset by peer]
rb2k has joined #nix-darwin
eraserhd2 has joined #nix-darwin
eraserhd has quit [Ping timeout: 264 seconds]
rb2k has quit [Ping timeout: 258 seconds]
rb2k has joined #nix-darwin
<abathur>
if anyone feels the urge to (or already did) gripe at Apple about the update/recovery issue, I opened a feedback last night that you can refer to: FB8997501
<dhess>
oh no, my nix-darwin updater just installed the old users again?
<dhess>
nooooo
<dhess>
hahaah ugh
<abathur>
ruhroh
<abathur>
though, this does answer a question for me
<abathur>
I've been wondering why the system I'm on right now has nixbld users since it's a single-user install; I'd just assumed that I goofed something at some point playing with installers
<__monty__>
I had this happen on a single-user install too, ages ago.
<dhess>
abathur: how can I delete a nixbld user, is there a single dscl command?
<dhess>
or is it multiple steps?
<abathur>
this shouldn't be that hard, though tbh I haven't been doing any of this work with nix-darwin atop, so I don't really know if it's going to keep messing with it or not
<dhess>
I can patch up nix-darwin so that it doesn't happen again (though coming up with a proper migration/fix will take more time)
<__monty__>
dhess: From my history, use at your own risk `dscl . -list /Users | while read user; printf "$user "; dsmemberutil checkmembership -U "$user" -G "nixbld"; end | grep "is a member" | cut -d " " -f 1;`
<abathur>
iirc it's just `sudo dscl . delete /Users/nixbld1`, but I think, per the trouble bauer had, that we also need to remove them from the group first
<__monty__>
Yeah, so that's just to list them, then I deleted the group and then the users in a loop.
<LnL->
nix-darwin has logic to both create and delete users
LnL- is now known as LnL
<abathur>
but yeah, in bash at least a little for builder in nixbld{1..32}; do things with $builder; done
<dhess>
LnL: so what would be a quick fix here so that I can rebuild nix-darwin and convince it to delete the users it just created?
<abathur>
doesn't it have assertions that'll stop it from deleting the last user, though?
<LnL>
users.knownUsers = genList (x: "nixbld${toString (i + 1)}") 32;
<dhess>
abathur: do I need to delete the group, too? Or is the group the same as the one you add your _nixbld users to?
<LnL>
same for the group
<abathur>
the group can stay
<dhess>
LnL: ahh so that will make nix-darwin assume that it doesn't manage those (non-existent) users and then it wont try to create them?
<LnL>
well it should since it manges the install
<abathur>
it looks like there's an option users.nix.configureBuildUsers
<LnL>
I haven't really been following the full thing, but adding a user account shouldn't break your system
<LnL>
so I kind of still don't understand what's going on
<abathur>
you'd think that :)
<abathur>
my best (but not entirely grounded) guess is that they're trying to do some sort of user state migration, and they're doing it to any users that don't fit their definition of a role account
<abathur>
(which our nixbld users do not)
<LnL>
so that would impy the entire users.users module borks the system?
<abathur>
not sure exactly what about them trips it up from there, perhaps it isn't expecting to get /var/empty as a homedir, or something
<abathur>
I don't know, should probably try to test for it
<LnL>
single user + darwin config might be easy to automate for testing :)
<abathur>
basically it seems to want "role" accounts to have names that start with an underscore, and UIDs in the range 200-400; I haven't extensively poked at this because it's time-expensive to iterate on, but renaming nixbld users and changing IDs to fit does stop the behavior
<abathur>
this is based on the dumb-luck to stumble on an edit they made to the usage info for sysadminctl, and some new flags they added to it
<LnL>
^ that's what initialises them during install so services.nix-daemon isn't insane to recover from with a single user install
<abathur>
I think so, try to force a build of something
<abathur>
Nix'll bark at you if it can't find the build users
<abathur>
unfortunately, I have no clue how or if it's even possible to automate update testing
<abathur>
these aren't just patently invalid, they're only breaking during updates
<abathur>
I guess maybe some of the fancy interaction that OSX-KVM or whatever does with the VM suggests that it might be possible to script the interactions to trigger an update
<abathur>
I'm a little miffed with them for also whiffing on the additions to sysadminctl so far
<abathur>
so its -addUser action has a new -roleAccount option, but it basically just asserts that the user name needs a leading underscore and a UID in the range
<abathur>
instead of just picking a free UID in the damn range and printing it...
<LnL>
as for the proper fix, I guess this needs to be updated to create different build users similar to the pr
<dhess>
yeah that is what I was planning to do, but there is also the need to migrate the existing ones. I guess incorporate abathur's script into the system activation scripts?
__monty__ has quit [Quit: leaving]
<dhess>
or I guess just check for the old ones & delete them if present
<dhess>
that's probably easier since you already have the user creation bits.
<dhess>
abathur: is there anything else you changed about the migrated users other than their names and their uids ?
rb2k has joined #nix-darwin
<LnL>
yeah, shouldn't be terribly complicated
<abathur>
depends on how technical we're getting
<abathur>
migration is a slightly different case
<LnL>
the installer could also only enable creation during install when the daemon is enabled, however that makes setting wrong options more dangerous
<abathur>
the migration superstitiously deletes some properties on the users
<abathur>
dsAttrTypeNative:_writers_passwd, which I found was still pointing to the old names; I gather this setting indicates which users are allowed to change the password of the current user
<LnL>
my point was to make things as straightforward as possible since some hidden and unused users doesn't hurt anybody
<abathur>
nod
<LnL>
and I still think that, this is just madness IMHO :D
<abathur>
oh, I agree
<abathur>
it took some self control not to rage when I finally wrote the feedback report last night
<abathur>
and to keep my snark at about a 2-3
<LnL>
the "/private/var/empty 1" is the only weird thing I've noticed about this
<abathur>
yeah
<abathur>
fiddling with that didn't help, but I do think the same migration process, or something similar, is causing it
<abathur>
when I get the users fixed up, it doesn't get changed to that anymore
<LnL>
we explicitly set the nfshomedir but for some reason that suffix gets added at some point
<abathur>
yeah
<LnL>
do you know if that happens immediately or is that only on long running systems (eg. previous upgrades)
<abathur>
my vague what-could-they-be-doing? musing on the empty_1 is that they're trying to migrate the user's directory for some reason, perhaps moving it out of the way before updating, and have code to avoid an overwrite
<abathur>
so when they come back at the end and it exists, they change it? but I still don't get why there aren't _32 of them if that's the case
<LnL>
yeah, I'm thinking more of some kind of migration locking over the homedir
<LnL>
so when it runs into multiple users with the same location stuff gets stuck
<abathur>
I don't; I do know that the update directly caused that to happen when I was testing
<abathur>
i.e., systems go into the update with fresh installs and /var/empty, and come out with /private/var/empty_1
<abathur>
but my current catalina system has a /var/'empty 1' directory that I've puzzled over before, so I suspect whatever causes that has been going on for a little longer
<LnL>
yeah it definitively considers them to be regular users, they have to be hidden explicitly
<abathur>
1.) my install might be different than yours since I'm running it fresh
<abathur>
and there may have been some change or fix since you created? not sure if you know what that field looked like before
<dhess>
abathur: Don't sweat it, it's cool. A lot of things have gone wrong over here since I first ran it :)
<dhess>
had to delete the nix-darwin-created users a few times now :)
<dhess>
I will try it on another machine next and let you know how it goes
<abathur>
yeah, I'd guess that might be to blame
<abathur>
it's possible that dscl . delete also cleans those up
<abathur>
and may have deleted the key when you got the last?
<LnL>
what a mess, imagine having to deal with user accounts that have actual state
<abathur>
since the migration just *renames* the users, it might be behaving a little differently
<abathur>
hehe
<dhess>
In theory, if I just change the user names and uids that nix-darwin checks for and creates if not present, then a `darwin-rebuild switch` will create the users for me and then I can just delete the old ones, right?
<LnL>
yeah, but both need to be in the known list
<abathur>
yeah, I don't know; as annoyed as I am, I'm glad it at least happened before nix#4289 landed and daemon installs become the default...