<cransom>
the machine without nixbld users originally went through normally.
<cransom>
NFSHomedirectory is /private/var/empty_1
<thefloweringash>
has anyone seen a successful upgrade (no recovery step) with multi-user nix?
<abathur>
interesting
<abathur>
not with a stock install, but I have, kinda, with mods
<abathur>
I am a bit flummoxed after the latest, I did a stock install and then changed the UserShell for each nixbld user from /sbin/nologin to /usr/bin/false like the majority of apple's users
<abathur>
and I was excited to see it install through without booting into recovery!
<abathur>
but then I realized it seems to have eaten the users
<abathur>
but not the group
<abathur>
so I may be on to something there, but I don't feel like I learned much :)
<abathur>
I may have goofed by not rebooting after changing the shells, idk
<thefloweringash>
have there been attempts to update the clang version for darwin? I think I remember hearing about it, but I'm not finding it when I search the issues
<LnL>
thefloweringash: there's a draft with some of the llvm changes I already worked on
<abathur>
latest attempt, changing the nixbld* NFSHomeDirectory to /private/var/empty, did fail into recovery
<abathur>
it does look like it changed those to /private/var/empty_1 in the user .plist files
<abathur>
that one's probably a dead-end
<abathur>
I did the reboot others have described and am comparing things between the big sur and catalina systems and one difference I see is that `dscl . read /Groups/nixbld` shows an extra "GroupMembers:" on big sur, not sure if it was there before the update
<abathur>
this field appears to have a GUID for each user
<abathur>
in addition to the GroupMembership: field which just has the username of each
rb2k has joined #nix-darwin
philr has quit [Ping timeout: 240 seconds]
<tristan[m]>
LnL: I'm kind of confused right now. I started looking at fixing the zsh environment setting stuff in Issue #158 here https://github.com/LnL7/nix-darwin/pull/286 but it became obvious that this wasn't the right way to do it and that Nix itself needs to be fixed and put its environment-setting code in `/etc/zshenv` rather than `/etc/zshrc`.
<tristan[m]>
ok so it was fixed for real in October
<abathur>
I think the may PR also broke other installer steps
<abathur>
oh, nm, maybe that was a different Pr
<abathur>
not disagreeing with backporting it, just making sure anyone who tries knows It Is Complicated
<abathur>
:]
rb2k_ has joined #nix-darwin
rb2k has quit [Ping timeout: 260 seconds]
rb2k_ has quit [Read error: Connection reset by peer]
rb2k has joined #nix-darwin
<abathur>
ah, drat, I guess the "GroupMembers:" thing is just big sur; I have the same after a Nix install before upgrading to 11.2
rb2k has quit [Ping timeout: 260 seconds]
rb2k has joined #nix-darwin
rb2k has quit [Read error: Connection reset by peer]
rb2k has joined #nix-darwin
footlooseboss has joined #nix-darwin
footlooseboss has quit [Client Quit]
footlooseboss has joined #nix-darwin
footlooseboss has quit [Client Quit]
philr has joined #nix-darwin
<abathur>
using an alternative idiom for hiding users--setting Password to "*" and not setting IsHidden--also booted into recovery :/
<tristan[m]>
wait so Nix causes this whole "booting into recovery after intalling a big sur" update shit?
<tristan[m]>
This problem has given me so much heartache, I've had to reinstall my macbook from time machine twice this week. First from updating to 11.1 and then again when updating to 11.2.
<abathur>
if you're using a daemon install, probably; others have had success just rebooting from recovery and getting in cleanly; as far as I can tell it has something to do with the nixbld users, presumably a state migration of some sort breaking
<tristan[m]>
Yeah I have a daemon install
<abathur>
though to be fair, Nix has had this code in daemon mode installer for over 4 years, and it was kicking around in proto-installers before that
<tristan[m]>
When I would reboot from recovery, it would just retry the upgrade process and fail half an hour later in a loop.
<tristan[m]>
I had to make a new APFS Volume, install a fresh version of Big Sur on it, run the migration assistant, restore from the old volume, then delete the old volume.
<abathur>
not sure, but multiple people have reported success rebooting out of it; I've tried it once while trying to nail the behavior down and it worked for me as well
<tristan[m]>
Ironically, the migration assistant allowed me to restore the nixbld users but I didn't.
<abathur>
well
<abathur>
they appear to survive the migration for the people who've rebooted out
<abathur>
but the only two things I've done in testing that have allowed me to bypass falling into recovery have been removing the users, and changing their UserShell
<abathur>
though in the latter case, the migration did eat the users
<abathur>
so it could be something else; that's just where the smoke seems to be
<abathur>
though I'm getting close to out of ideas at this point
<abathur>
better yet, there's already an 11.3 beta out :)