After Ugrade, Jammy requires me to create a new user, although users are present

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1971559/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Not sure if ubiquoty package is the right place, please change if necessary.

Could you take a photo of the dialog? Is that the initial setup started on the login screen?

Which desktop environment do you use?

It could that the code doesn't detect you have an user, is that a normal local user? what is the uid?

Sorry, I'm far from that machine at the moment, but I'll try describing:
- Desktop environment: GNOME (standard Ubuntu Desktop)
- I don't see the login screen, Ubuntu boots through to the desktop and shows the dialog.
- dialog fills almost the whole desktop and nothing can be done except finishing that dialog.
- it says (from my mind): only a few steps are required to finish setip, this wizard will help you create an account. Then ist prompts for a new user name, login id, locale, time zone, etc.

That's the dialog.

The local user with sudo rights has uid 1000:

root@rechner2-3-12:~# id linadmin
uid=1000(linadmin) gid=1000(linadmin) Gruppen=4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare),1000(linadmin)

could you share the output of

$ grep linadmin /etc/passwd

?

Was /home pointing somewhere that doesn't exist anymore? Or is it an LDAP problem?

root@rechner2-3-12:~# grep linadmin /etc/passwd
linadmin:x:1000:1000:Linux-Administrator,,,:/home/linadmin:/bin/bash

/home/linadmin is a local directory and linadmin is a locally configured user, no LDAP account.

and you have /bin/bash available?

could you add the 'journalctl -b 0' log from the system to the report?

what's the output of

$ dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers

oh also, do you still have the system in a state showing the issue? because otherwise poking at the current state of things isn't going to help us understand what was wrong

/bin/bash is availble, I can su to linadmin and even connect as linadmin by ssh.

Journal is attached.

Yes, system is still in this state. I went through the dialog once and created a user. After that the machine booted into th login screen and worked. Then I removed the new user with "deluser" and at next boot I was back at the dialog.
So, yes, it appears the code does not detect that there are other users.

dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers
method return time=1651757139.332087 sender=:1.8 -> destination=:1.153 serial=94 reply_serial=2
   array [
   ]

I'm logged in remotely via ssh.

linadmin is definitely a user with ultimate sudo rights:

root@rechner2-3-12:~# sudo -U linadmin --list
Passende Defaults-Einträge für linadmin auf rechner2-3-12:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

Der Benutzer linadmin darf die folgenden Befehle auf rechner2-3-12 ausführen:
    (ALL : ALL) ALL

Don't know if this helps:

root@rechner2-3-12:~# ps -ef|grep initial
gnome-i+ 2044 1829 0 08:20 tty1 00:00:00 /usr/libexec/gdm-x-session dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup
gnome-i+ 2081 2044 0 08:20 tty1 00:00:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup
gnome-i+ 2083 2081 0 08:20 tty1 00:00:00 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup
gnome-i+ 2366 2083 0 08:20 tty1 00:00:14 /usr/libexec/gnome-initial-setup
root 8589 8365 0 15:31 pts/0 00:00:00 grep initial

Do you have a /var/lib/AccountsService/users/linadmin and if so does it have a SystemAccount= key and what is its value?

doing

$ sudo /usr/libexec/accounts-daemon --debug

should help figuring out why the user is filtered out

root@rechner2-3-12:~# cat /var/lib/AccountsService/users/linadmin
# do not show user in greeter

[User]
SystemAccount=true

Ah! This could be it! lindamin is marked as SystemAccount, because our users shall not see it in the list of accounts on the login screen …

root@rechner2-3-12:~# /usr/libexec/accounts-daemon --debug
(accounts-daemon:9005): DEBUG: entering main loop
(accounts-daemon:9005): DEBUG: Changing permission of /var/lib/AccountsService/users/vorlage to 0600
(accounts-daemon:9005): DEBUG: Changing permission of /var/lib/AccountsService/users/windows to 0600
(accounts-daemon:9005): DEBUG: Changing permission of /var/lib/AccountsService/users/linadmin to 0600
(accounts-daemon:9005): DEBUG: Changing permission of /var/lib/AccountsService/users/gnome-initial-setup to 0600
(accounts-daemon:9005): DEBUG: Changing permission of /var/lib/AccountsService/users/gdm to 0600
(accounts-daemon:9005): DEBUG: skipping user: root
(accounts-daemon:9005): DEBUG: skipping user: daemon
(accounts-daemon:9005): DEBUG: skipping user: bin
(accounts-daemon:9005): DEBUG: skipping user: sys
(accounts-daemon:9005): DEBUG: skipping user: sync
(accounts-daemon:9005): DEBUG: skipping user: games
(accounts-daemon:9005): DEBUG: skipping user: man
(accounts-daemon:9005): DEBUG: skipping user: lp
(accounts-daemon:9005): DEBUG: skipping user: mail
(accounts-daemon:9005): DEBUG: skipping user: news
(accounts-daemon:9005): DEBUG: skipping user: uucp
(accounts-daemon:9005): DEBUG: skipping user: proxy
(accounts-daemon:9005): DEBUG: skipping user: www-data
(accounts-daemon:9005): DEBUG: skipping user: backup
(accounts-daemon:9005): DEBUG: skipping user: list
(accounts-daemon:9005): DEBUG: skipping user: irc
(accounts-daemon:9005): DEBUG: skipping user: gnats
(accounts-daemon:9005): DEBUG: skipping user: nobody
(accounts-daemon:9005): DEBUG: skipping user: systemd-timesync
(accounts-daemon:9005): DEBUG: skipping user: systemd-network
(accounts-daemon:9005): DEBUG: skipping user: systemd-resolve
(accounts-daemon:9005): DEBUG: skipping user: syslog
(accounts-daemon:9005): DEBUG: skipping user: _apt
(accounts-daemon:9005): DEBUG: skipping user: messagebus
(accounts-daemon:9005): DEBUG: skipping user: uuidd
(accounts-daemon:9005): DEBUG: skipping user: lightdm
(accounts-daemon:9005): DEBUG: skipping user: whoopsie
(accounts-daemon:9005): DEBUG: skipping user: avahi-autoipd
(accounts-daemon:9005): DEBUG: skipping user: colord
(accounts-daemon:9005): DEBUG: skipping user: speech-dispatcher
(accounts-daemon:9005): DEBUG: skipping user: hplip
(accounts-daemon:9005): DEBUG: skipping user: kernoops
(accounts-daemon:9005): DEBUG: skipping user: pulse
(accounts-daemon:9005): DEBUG: skipping user: rtkit
(accounts-daemon:9005): DEBUG: skipping user: saned
(accounts-daemon:9005): DEBUG: skipping user: usbmux
(accounts-daemon:9005): DEBUG: loaded user: linadmin
(accounts-daemon:9005): DEBUG: skipping user: sshd
(accounts-daemon:9005): DEBUG: skipping user: ntp
(accounts-daemon:9005): DEBUG: skipping user: geoclue
(accounts-daemon:9005): DEBUG: skipping user: nm-openvpn
(accounts-daemon:9005): DEBUG: skipping user: postfix
(accounts-daemon:9005): DEBUG: skipping user: guest-3qs2su
(accounts-daemon:9005): DEBUG: loaded user: windows
(accounts-daemon:9005): DEBUG: loaded user: vorlage
(accounts-daemon:9005): DEBUG: skipping user: statd
(accounts-daemon:9005): DEBUG: skipping user: cups-pk-helper
(accounts-daemon:9005): DEBUG: skipping user: gdm
(acco...

Indeed, all local accounts are marked as system accounts, because they all serve administrative uses in one way or the other, and shall not be seen by normal users.

What was the behaviour in 20.04? Was any user being listed? How did you mark those accounts as SystemAccount=true?

If you don't want usernames to be listed the standard way would be to follow the steps there
https://help.gnome.org/admin/system-admin-guide/stable/login-userlist-disable.html.en

Behaviour in 20.04 was like it is in 22.04: Once I went through the dialog and created one no-system user, the login screen shows all accounts not listed as "system". I.e. all of our LDAP users (which are the only ones relevant to our users).

I manually marked those accounts as system, to have them excluded from the login list.

The link you posted is about disabling the user list altogether, which is not what we we want. We want to have the user list but have it show only standard, no-special users.

Thanks for the details, you got me slightly confused now though. Was 'linadmin' that user and did it got somewhat flagged as system user on upgrade? Or did the user you created back then got removed somehow? It sounds like you had workarounded the problem in 20.04 and that the workaround should have continued working after the upgrade...

I'm unsure what would be the right behaviour there. The automatic wizard start is intended to be able to ship a 'preinstalled but not configured yet' system to users and let them create their account on first start.

Non system accounts flagged as systemuser should perhaps could as an existing user in that logic even if they aren't explicitly displayed?

Sebastien, thanks for your reply.
First of all, considering that this is a somewhat special (though not unlikely) setup on our side, you may demote this bug from importance high to lower. This is to remove strain on you developers, this bug will only concern special institutional setups like ours and never will concern private users. Take a break ;-).

The problem did not appear upon update to 20.04. Was there a comparable "initial-setup" dialog in 20.04?

This is a multi-user installation at a school.
I flagged the linadmin user (and other local users we utilize for managing our services) as being system users manually. I did that to not have them displayed in gdm's user list at tje login page. There may be more appropriate ways of doing this, if you know of them (lest disabling the user list altogether), let me know, please.

At the tome being, I can workaround the issue by creating some local dummy user nit tagged as system.

My suggestion is to have included into the initial-install wizard an option to skip the dialog if root is sure about it.

> Non system accounts flagged as systemuser should perhaps could as an existing user in that logic even if they aren't explicitly displayed?

I'd expect that to depend very much on the installation at hand (in our case it would), but that can't be decided programmatically. I'd opt for a way of skipping the initial-install wizard for advanced users. Possibly hidden below an "advanced setup” option and with a warning about being left without any usable account. But there should be a way of skipping it.

Indeed that's quite a special case. Checking upstream another available workaround that doesn't involve adding a local account is to edit /etc/gdm3/custom.conf to set

[daemon]
InitialSetupEnable=false

https://gitlab.gnome.org/GNOME/gdm/-/blob/main/daemon/gdm-display.c#L1690

Ah, that's what I was looking for, thanks.