Bug 1780963 - After update booting into 'create new user' guide instead of my account
Summary: After update booting into 'create new user' guide instead of my account
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 30
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-08 19:14 UTC by Caolán Mac Tíre
Modified: 2020-05-26 18:06 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-26 18:06:39 UTC
Type: Bug


Attachments (Terms of Use)
Altered packages during the bad update (8.44 KB, text/plain)
2019-12-08 19:14 UTC, Caolán Mac Tíre
no flags Details

Description Caolán Mac Tíre 2019-12-08 19:14:16 UTC
Created attachment 1643097 [details]
Altered packages during the bad update

Firstly, I don't know under which component this should be listed.
Secondly, I do have setup auto-login, if it's relevant.

Description of problem:
I updated system and now it boots into guide for creating new user with welcome in all sorts of languages. This happens after every reboot. 
I tried to create new user as suggested by another user who experiencing similar issue (on f31), however, to no avail. 
This is the thread: 
https://ask.fedoraproject.org/t/fedora-30-after-update-there-is-create-of-new-user-guide-instead-of-auto-login/4492

I was able to switch to my account with the following steps:
1. logout
2. switch to console with Alt+Fx
3. switch back to GUI with Alt+F1
4. and that brings me to my account

Attached is the list of altered packages.

Comment 1 Rubén Lledó 2019-12-19 21:26:51 UTC
Same issue, but it only happens sometimes, not every time I boot the computer.

Comment 2 Michael Catanzaro 2019-12-29 18:04:21 UTC
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'],)

Comment 3 Michael Catanzaro 2019-12-29 18:11:36 UTC
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.

Comment 4 Caolán Mac Tíre 2019-12-30 17:34:47 UTC
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?

Comment 5 Michael Catanzaro 2019-12-30 20:23:32 UTC
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.

Comment 6 Caolán Mac Tíre 2019-12-30 21:42:24 UTC
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.

Comment 7 Rubén Lledó 2020-01-01 13:04:10 UTC
(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!

Comment 8 Ben Cotton 2020-04-30 20:34:59 UTC
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.

Comment 9 Ben Cotton 2020-05-26 18:06:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.