Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1366896 - cannot start user session (gdm returns back to the login page)
Summary: cannot start user session (gdm returns back to the login page)
Keywords:
Status: CLOSED DUPLICATE of bug 1373169
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-14 11:34 UTC by Christian Stadelmann
Modified: 2016-09-12 14:15 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1195485
Environment:
Last Closed: 2016-09-12 13:02:57 UTC


Attachments (Terms of Use)

Description Christian Stadelmann 2016-08-14 11:34:47 UTC
Bug is still present on Fedora 24. Since nobody cares to reopen the original bug report I'm cloning this bug.

This bug cannot be reproduced always on Fedora 24, but it still happens quite often.

+++ This bug was initially created as a clone of Bug #1195485 +++

Description of problem:

After logging in gdm the screen flashes a couple of times and returns back to the login prompt.

Version-Release number of selected component (if applicable):

Freshly installed F22.


How reproducible:

100%

Steps to Reproduce:
1. Log in using gdm.
2. Wait.


Actual results:

After a couple of screen flashes the login prompt is back.


Expected results:

Gnome session logged in.


Additional info:

Freshly installed Fedora 22 from dl.fedoraproject.org. Logging into the console works. Starting a (Gnome) session using startx works.

--- Additional comment from Fedora Blocker Bugs Application on 2015-02-23 17:11:30 EST ---

Proposed as a Blocker for 22-alpha by Fedora user pavlix using the blocker tracking app because:

 The default display manager cannot log the user in. Expert knowledge is needed to get logged in at all.

--- Additional comment from Stephen Gallagher on 2015-02-24 09:39:00 EST ---

Pavel, is this still an issue with the latest packages? I'm running a Fedora Workstation 22 system that I installed freshly from the 20150218 nightly compose of Fedora Workstation Live and have updated ever since.

What installation media did you use? What package set did you choose in Anaconda (if not a Live installer)?

--- Additional comment from Pavel Šimerda (pavlix) on 2015-02-24 10:17:59 EST ---

(In reply to Stephen Gallagher from comment #2)
> Pavel, is this still an issue with the latest packages? I'm running a Fedora
> Workstation 22 system that I installed freshly from the 20150218 nightly
> compose of Fedora Workstation Live and have updated ever since.

To be honest, I'm not getting it right now but I didn't update any packages, I only changed network configuration and probably nothing else. I might try later.

> What installation media did you use? What package set did you choose in
> Anaconda (if not a Live installer)?

I used PXE boot:

http://dl.fedoraproject.org/pub/fedora/linux/development/22/x86_64/os/images/pxeboot/

I chose Fedora Workstation and didn't do any other changes except reclaiming disk space. Since yesterday, I didn't get any updates using yum.

--- Additional comment from Pavel Šimerda (pavlix) on 2015-02-25 09:24:46 EST ---

The issue is back. I don't know what exactly is different in the system between the time when it works and the time when it fails.

--- Additional comment from Pavel Šimerda (pavlix) on 2015-02-25 09:29:45 EST ---

One coincidence is that now it fails and I'm not connected to a network. After connecting and restarting gdm.service I can log in.

--- Additional comment from Pavel Šimerda (pavlix) on 2015-02-25 09:31:49 EST ---

One other detail is that I'm using a hostname that isn't resolvable, but that's *not* changing between connected and disconnected state. I do not consider a non-resolvable FQDN hostname a valid reason for GUI issues anyway, so I'm mentioning it just in case it somehow affected the situation.

--- Additional comment from Matthias Clasen on 2015-02-26 08:48:44 EST ---

the most important information is missing here: rpm -q gdm

--- Additional comment from Chris Murphy on 2015-03-02 02:56:39 EST ---

I can't reproduce this with Alpha TC7, either BIOS or (U)EFI baremetal, or VirtualBox. (On a Mac with both AMD Radeon HD 6750M and i915 graphics, I get a lot of flicker at gdm which clears after login, nothing useful is in dmesg or journal. But this would be a different bug.)

--- Additional comment from Petr Schindler on 2015-03-02 13:14:59 EST ---

Discussed at today's blocker review meeting [1].

This bug was rejected as Alpha Blocker - This bug doesn't seem to be reproducible. If more information comes to the surface, please repropose with steps to reproduce.

http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-02/

--- Additional comment from Alexander Bisogiannis on 2015-03-02 18:22:02 EST ---

I just downloaded the boot.iso from [0] and I can confirm that in VirtualBox 4.3.22 r98236.

The iso boots but fails to bring up the graphical interface and thus anaconda.


Abis.


[0]
http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/22/x86_64/os/images/

--- Additional comment from Chris Murphy on 2015-03-02 19:38:15 EST ---

(In reply to Alexander Bisogiannis from comment #10)
> The iso boots but fails to bring up the graphical interface and thus
> anaconda.

Sounds like bug 1196676.

--- Additional comment from Christian Stadelmann on 2016-04-17 15:10:23 EDT ---

This issue still happens to me on Fedora 23 and 24. It only fails after being logged in before.

--- Additional comment from Christian Stadelmann on 2016-06-11 15:44:27 EDT ---

I still run into this bug fairly often.

Steps to reproduce for me:
1. log in into a gnome session (both gnome+x11 and gnome+wayland work).
2. Open gnome-system-monitor. Note the console/tty ("Session" column) values
3. logout
4. through tty, make sure there is at least one process running with with the same session as noted down in step 2.
5. from gdm, try to login again (same user)

What happens:
Login fails, I'm immediately sent back to login screen.

What should happen:
Processes on a specific session should be ended when the session ends.
Even if a process is running at the session, open a new session anyway (previous session might have failed).

Additional info:
Output to syslog:Jun 11 21:22:19 hostname audit[10054]: USER_AUTH pid=10054 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix,pam_gnome_keyring acct="username" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Jun 11 21:22:19 hostname audit[10054]: USER_ACCT pid=10054 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="username" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Jun 11 21:22:19 hostname audit[10054]: CRED_ACQ pid=10054 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix,pam_gnome_keyring acct="username" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
Jun 11 21:22:19 hostname audit[10054]: USER_ROLE_CHANGE pid=10054 uid=0 auid=1000 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty4 res=success'
Jun 11 21:22:19 hostname audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jun 11 21:22:19 hostname audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jun 11 21:22:19 hostname systemd-logind[821]: New session 5 of user username.
Jun 11 21:22:19 hostname systemd[1]: Started Session 5 of user username.
Jun 11 21:22:19 hostname gdm-password][10054]: pam_unix(gdm-password:session): session opened for user username by (uid=0)
Jun 11 21:22:19 hostname audit[10054]: USER_START pid=10054 uid=0 auid=1000 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit,pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring acct="username" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty4 res=success'
Jun 11 21:22:19 hostname audit[10054]: USER_LOGIN pid=10054 uid=0 auid=1000 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success'

--- Additional comment from Christian Stadelmann on 2016-06-11 15:55 EDT ---

I've attached a more detailed log.

--- Additional comment from Fedora End Of Life on 2016-07-19 08:51:10 EDT ---

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.

Comment 1 Christian Stadelmann 2016-09-12 13:02:57 UTC

*** This bug has been marked as a duplicate of bug 1373169 ***


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