Bug 15113 - 5beta2: After install from Gnome LiveCD created user is not shown in GDM
Summary: 5beta2: After install from Gnome LiveCD created user is not shown in GDM
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
Whiteboard: 5beta2
Depends on:
Blocks: 14069
  Show dependency treegraph
Reported: 2015-01-22 12:07 CET by claire robinson
Modified: 2015-02-24 13:24 CET (History)
4 users (show)

See Also:
Source RPM:
Status comment:

journalctl-b.txt (194.59 KB, text/plain)
2015-01-22 12:28 CET, claire robinson

Description claire robinson 2015-01-22 12:07:40 CET
Installed 5beta2 Gnome LiveCD to sda7 & 8 in dual boot with mga4

After reboot, medias were added and users created root and user, but user is not shown in GDM. In fact no users were shown in GDM, only the option to manually enter one. 

I suspect this has to do with the move to UID/GID 1000 and confirmed that the user is created as UID/GID 1000.

Login proceeded normally once user details were manually entered.


Steps to Reproduce:
Comment 1 claire robinson 2015-01-22 12:28:48 CET
Created attachment 5832 [details]

Jan 22 10:58:15 localhost gnome-session[2147]: Gjs-Message: JS LOG: Error calling StartServiceByName for org.freedesktop.PackageKit: Timeout was reached
Jan 22 10:58:15 localhost dbus[763]: [system] Failed to activate service 'org.freedesktop.PackageKit': timed out
Jan 22 10:58:28 localhost gnome-session[2147]: (gnome-shell:2185): AccountsService-WARNING **: ActUserManager: user (null) has no username (object path: /org/freedesktop/Accounts/User1
Jan 22 10:58:28 localhost realmd[2318]: explicitly releasing service: :1.52
Jan 22 10:58:28 localhost gdm-session-worker[2326]: <5>AccountsService: ActUserManager: user (null) has no username (object path: /org/freedesktop/Accounts/User1000, uid: 0)
Jan 22 10:58:28 localhost gdm-session-worker[2326]: <5>AccountsService: ActUserManager: user (null) has no username (object path: /org/freedesktop/Accounts/User1000, uid: 0)
Jan 22 10:58:28 localhost gdm-password][2326]: pam_succeed_if(gdm-password:auth): requirement "user ingroup nopasswdlogin" not met by user "user"
Jan 22 10:58:30 localhost gdm-password][2326]: pam_tcb(gdm-password:auth): Authentication passed for user from (uid=0)
Jan 22 10:58:30 localhost gdm-session-worker[2326]: <5>could not save session and language settings
Jan 22 10:58:30 localhost systemd[2330]: pam_tcb(systemd-user:session): Session opened for user by (uid=0)
claire robinson 2015-01-22 12:30:03 CET

CC: (none) => mageia, olav, pterjan, tmb

claire robinson 2015-01-22 12:30:23 CET

Whiteboard: (none) => 5beta2

Comment 2 claire robinson 2015-01-22 12:31:07 CET
adding as a blocker

Blocks: (none) => 14069
Priority: Normal => release_blocker

Comment 3 claire robinson 2015-01-22 15:50:29 CET
Doesn't seem to happen from the live dvd
Colin Guthrie 2015-02-05 20:49:37 CET

Assignee: bugsquad => mageia

Comment 4 Colin Guthrie 2015-02-08 21:55:01 CET
OK, so this happens because:

1. The user is created as part of the X11 "first-install" process.
2. The accounts-daemon daemon does not automatically pickup new users.

I was able to replicate the issue in the gnome-live dvd after installing, and then logging out (not rebooting). The user is not listed.

If I restarted the accounts-service, the user is noticed and things work OK (for me at least).

I shall try and put in a systemctl try-restart accounts-daemon into our user code and see if that helps.
Comment 5 Mageia Robot 2015-02-08 22:36:44 CET
commit 2969bde783d7e815a9867fe323e17394369579aa
Author: Colin Guthrie <colin@...>
Date:   Sun Feb 8 21:17:53 2015 +0000

    users: Make sure to restart accounts-daemon after adding users (mga#15113)
    This prevents various details being loaded about the user when they first
    login (including being listed in GDM and other user editing bits within
    It also has some effect on i18n where the user's language settings are
    totally reset (to en_US) rather than inheriting the system prefs
    which seems to be the problem presented in mga#14476
 Commit Link:

 Bug links:
Comment 6 Colin Guthrie 2015-02-08 22:39:03 CET
The above seemed to do the trick for me but I can only test in a hacked up live env so it's not the best test in the world. It did seem to work tho'!
Comment 7 claire robinson 2015-02-24 12:54:42 CET
Sorry for the delay in responding. This appears to be fixed in beta3 so closing now, thanks Colin.
Comment 8 claire robinson 2015-02-24 13:24:37 CET
actually closing

Resolution: (none) => FIXED

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