Login package changes MIN_UID in /etc/login.defs -> AccountsService/GDM then ignores existing user (UID 501) -> starts gnome-inital-setup to create user
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gnome-initial-setup (Ubuntu) |
New
|
Low
|
Unassigned |
Bug Description
On May 8. 2018 I was prompted to upgrade from 17.10 to 18.04.
The upgrade went smooth except that the installer asked me if it could make changes to /etc/login.defs. I thought it was supposed to not ask questions (and stall the upgrade if I was away from the computer), but I pressed yes and it continued. I pressed yes since I had not personally modified this file as far as I can remember and was not particularly attached to its contents.
After reboot gnome-initial-setup wants me to create a new user. There is no (obvious) way to login with my old user, but Ctrl+Alt+F2 luckily worked---I could log in and all my files where still there. I tried changing UID_MIN in /etc/login.defs back to 500 from 1000 (I believe this was the change I was prompted about), but I still could not login graphically, so the /etc/login.defs change may have been unconnected to the bug.
I was able to figure out that the offending program was called gnome-initial-setup and an "apt purge gnome-initial-
affects: | shadow (Ubuntu) → gnome-initial-setup (Ubuntu) |
Changed in gnome-initial-setup (Ubuntu): | |
importance: | Undecided → Low |
What has occurred is due to the change of UID_MIN AccountsService has decided that your existing user (501) is now a system user. GDM has then decided that there are no user accounts on the system, so has triggered gnome-initial-setup to create one.
I suspect if you had rebooted after changing UID_MIN back it would have worked fine (user showed in GDM, gnome-initial-setup not run).
I'll assign this to the 'login' package which has decided to change the MIN_UID to 1000 - it may be this is an issue on older systems that used to have this value.