goglosh@openmailbox.org skribis: > I got this unexpected behaviour. I used `guix system reconfigure ...` > to make a new system instance, used it for a while, and later booted > back into the old system. I used diferent names for the user in the > first and second system, let's call them sys1user and sys2user. I > booted into the old system and tried to login as sys1user (the user > created with that system) with it's password and this was no longer > possible. Yes, good point. I see how this may look confusing. When you boot a specific generation of the system, it gets to see only the set of users that were declared for that generation. So one sees ‘sys1user’ and ‘root’, and the other has ‘sys2user’ and ‘root’. So when you booted the new generation, the ‘sys1user’ account was deleted and the ‘sys2user’ account was created. When you booted again into the old generation, ‘sys1user’ was added back and ‘sys2user’ was deleted. This is on purpose, see . Now, the problem is that passwords are state that is outside of GuixSD’s control. Passwords are stored in /etc/shadow, and removing a user account removes its entry in /etc/shadow. This is why you would get uninitialized passwords when booting back in the old generation. I think this is an acceptable “limitation” of the approach though. > I then rebooted back into the new system, only to find the exact same > problem. in /home/sys2user all files belonged to some user called > 30011. Same issue: Unless the ‘user-account’ declaration asked for a specific user ID via the ‘uid’ field (see ), the UID is assigned when the account is first created. What happens here is that maybe ‘sys2user’ got the UID 30011 at some point, and then got a different one. Again, I don’t thin there’s much that GuixSD can do here, because it doesn’t control what files are created under which UID in /home, etc. Does that make sense? Thanks, Ludo’.