Same issue, but it only happens sometimes, not every time I boot the computer.

None of the packages altered during that update could affect this.

So here's the code that decides whether to run initial setup, from gdm-manager.c:

static gboolean
wants_initial_setup (GdmDisplay *self)
{
        GdmDisplayPrivate *priv;
        gboolean enabled = FALSE;
        gboolean forced = FALSE;

        priv = gdm_display_get_instance_private (self);

        if (already_done_initial_setup_on_this_boot ()) {
                return FALSE;
        }

        if (kernel_cmdline_initial_setup_force_state (&forced)) {
                if (forced) {
                        g_debug ("GdmDisplay: Forcing gnome-initial-setup");
                        return TRUE;
                }

                g_debug ("GdmDisplay: Forcing no gnome-initial-setup");
                return FALSE;
        }

        /* don't run initial-setup on remote displays
         */
        if (!priv->is_local) {
                return FALSE;
        }

        /* don't run if the system has existing users */
        if (priv->have_existing_user_accounts) {
                return FALSE;
        }

        /* don't run if initial-setup is unavailable */
        if (!can_create_environment ("gnome-initial-setup")) {
                return FALSE;
        }

        if (!gdm_settings_direct_get_boolean (GDM_KEY_INITIAL_SETUP_ENABLE, &enabled)) {
                return FALSE;
        }

        return enabled;
}

So we see there's only two conditions that can trigger initial setup:

 * gnome.initial-setup=1 specified on kernel command line, OR
 * No existing user accounts (as determined by accountsservice daemon)

So my guess is that accountsservice is somehow broken. Please check by running:

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts --method org.freedesktop.Accounts.ListCachedUsers

from a tty (Ctrl+Alt+F3 after you reach the initial setup prompt). It should output something like:

([objectpath '/org/freedesktop/Accounts/User1000'],)

Also check:

$ systemctl status accounts-daemon.service

Should say: Active: active (running).

If accountsservice is not running, it looks like we currently launch the initial setup process. Arguably it might be better to crash gnome-shell instead, since creating a new user account is not going to work, but that might be tricky to implement since it's currently set up to respawn itself if it crashes, and we don't want that happening as an infinite loop. So starting initial setup might not be great, but it's as plausible as any other failure path here.

Thank you Michael for resolving my issue.

The problem was indeed with the accounts-daemon.service - it was masked. By myself. I read this article on linux.com [1] where it was pointed out as something that could be stopped. So I did as I'm trying to make Fedora a bit swifter for my old computer. I completely forgot about that, though the bug appeared short after that alteration. I enabled the service and login works as expected. 

[1] https://www.linux.com/tutorials/cleaning-your-linux-startup-process/

That said, I am not sure about the other guys and their problem. Should they open new ticket?

Yeah if you intentionally disable accountsservice, GNOME will indeed no longer be able to find any user accounts to log into. :) At the time that article was written, Ubuntu was not using GNOME, so it probably didn't matter to Ubuntu users back then. Internet advice can be dangerous. ;)

Now in Rubén's case, the bug is reported to occur only sporadically, so that will be somewhat different, yes. If Rubén could try the debugging steps I suggested above to find out, then we might or might not decide to treat it as a separate issue.

I'll leave this bug open in case Ray has any preferences as to whether we should be entering initial setup in this case.

Yeah, absolutely, it can be :D Though this is more about me being forgetful and not connecting these two things together! Well, lesson learnt I hope. Thank you one more time, sir.

(In reply to Michael Catanzaro from comment #5)
> Yeah if you intentionally disable accountsservice, GNOME will indeed no
> longer be able to find any user accounts to log into. :) At the time that
> article was written, Ubuntu was not using GNOME, so it probably didn't
> matter to Ubuntu users back then. Internet advice can be dangerous. ;)
> 
> Now in Rubén's case, the bug is reported to occur only sporadically, so that
> will be somewhat different, yes. If Rubén could try the debugging steps I
> suggested above to find out, then we might or might not decide to treat it
> as a separate issue.
> 
> I'll leave this bug open in case Ray has any preferences as to whether we
> should be entering initial setup in this case.

Hello.

It's been a few weeks since the last occurrence of this issue appeared in my computer. As soon as it comes up again, I'll follow your debbuging steps and let you know.

Regards!

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.