Hide Forgot
Created attachment 1150089 [details] a photo of a screen with looping messages on a failed boot Description of problem: After recent updates a boot sequence goes into what looks like an inifinite loop (on some attempts I was waiting for over 8 minutes before giving up) with what look like failed attempts to start gdm. At least this looks that was from a repeating spillage on a screen. A photo of a screen attached. Luckily I still can boot to a level 3 but attempts to turn on level 5 leave no other option but a power switch. After a boot to level 3 in journalctl for the previous session it is possible to find something like that: ............. Apr 23 20:13:56 YYY /usr/libexec/gdm-x-session[1707]: KABINI, KABINI, KABINI, MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, Apr 23 20:13:56 YYY /usr/libexec/gdm-x-session[1707]: MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, Apr 23 20:13:57 YYY gdm-launch-environment][1679]: pam_unix(gdm-launch-environment:session): session closed for user gdm Apr 23 20:13:57 YYY audit[1679]: USER_END pid=1679 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success' Apr 23 20:13:57 YYY kernel: audit: type=1106 audit(1461464037.238:285): pid=1679 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success' Apr 23 20:13:57 YYY kernel: audit: type=1104 audit(1461464037.411:286): pid=1679 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success' Apr 23 20:13:57 YYY audit[1679]: CRED_DISP pid=1679 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty1 res=success' Apr 23 20:13:57 YYY systemd-logind[593]: Removed session c14. -- Subject: Session c14 has been terminated -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat -- -- A session with the ID c14 has been terminated. Apr 23 20:13:57 YYY gdm[1210]: Child process -1707 was already dead. Apr 23 20:13:57 YYY gdm[1210]: Child process 1679 was already dead. Apr 23 20:13:57 YYY gdm[1210]: Unable to kill session worker process Apr 23 20:13:57 YYY systemd[1]: Stopping User Manager for UID 42... .............. Version-Release number of selected component (if applicable): gdm-3.20.1-1.fc25.x86_64 How reproducible: always Additional info: I cannot exclude that xorg-x11-server-Xorg, which was updated in this batch to 1.18.3-2.fc25.x86_64 from a _working_ 1.18.3-1.fc25.x86_64 is screwing up here but the boot sequence with systemd in a case of failure is so opaque that it is hard to recognize what is really screwing up.
PING! Any comments and/or sage advice? It is about two weeks later and the current kernel is 4.6.0-0.rc6.git4.1.fc25.x86_64 and xorg-x11-server-Xorg-1.18.3-3.fc25 but boot still fails the same as before. Just in case - selinux is on this installation turned off and adding selinux=0 to a boot command does not change anything. The even more serious issue is that a failed component in a boot process is maniacally attempting in circles a failed operation, thus blocking the whole boot, instead of failing and allowing for a possibly incomplete boot where a user may try to diagnose and remedy a problem.
Apr 23 20:13:56 YYY /usr/libexec/gdm-x-session[1707]: KABINI, KABINI, KABINI, MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, Apr 23 20:13:56 YYY /usr/libexec/gdm-x-session[1707]: MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, MULLINS, Apr 23 20:13:57 YYY gdm-launch-environment][1679]: pam_unix(gdm-launch-environment:session): session closed for user gdm ^-- that's weird, KABINI and MULLINS are apparently AMD APUs . no idea what's going on. does putting Enable=true in the [debug] section of /etc/gdm/custom.conf provide any additional clues?
(In reply to Ray Strode [halfline] from comment #2) > > > no idea what's going on. does putting Enable=true in the [debug] section of > /etc/gdm/custom.conf provide any additional clues? Yes, I guess so, as I collected various entries in this style: May 09 15:45:55 dyna1.home.front audit[1913]: ANOM_ABEND auid=4294967295 uid=42 gid=42 ses=4294967295 pid=1913 comm="Xorg" exe="/usr/libexec/Xorg" sig=6 May 09 15:45:55 dyna1.home.front audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@2-1917-0 comm="systemd" exe="/usr/lib/systemd/systemd" May 09 15:45:54 dyna1.home.front gdm[1886]: GdmDisplay: seat id: (null) May 09 15:45:55 dyna1.home.front systemd[1]: Started Process Core Dump (PID 1917/UID 0). Moreover in /etc/gdm/custom.conf there are the following lines: [daemon] # Uncoment the line below to force the login screen to use Xorg # WaylandEnable=false Configured this way gdm does start. Only if I will uncomment 'WaylandEnable=false' then I see stuff like: Process 1897 (Xorg) of user 42 dumped core. Stack trace of thread 1897: #0 0x00007f159adfb5e5 raise (libc.so.6) #1 0x00007f159adfd1ea abort (libc.so.6) #2 0x000000000059b34e OsAbort (Xorg) #3 0x00000000005a0f63 AbortServer (Xorg) #4 0x00000000005a1d4d FatalError (Xorg) #5 0x000000000049a919 xf86OpenConsole (Xorg) #6 0x000000000047c09d InitOutput (Xorg) #7 0x0000000000439816 dix_main (Xorg) #8 0x00007f159ade61e1 __libc_start_main (libc.so.6) #9 0x0000000000423a49 _start (Xorg) and similar and with the following too: ..... May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (==) Depth 24 pixmap format is 32 bpp May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (WW) glamor requires at least 128 instructions (64 reported) May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) modeset(0): Failed to initialize glamor at ScreenInit() time. May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: Fatal server error: May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) AddScreen/ScreenInit failed for driver 0 May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: Please consult the Fedora Project support May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: at http://wiki.x.org May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: for help. May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) Please also check the log file at "/var/lib/gdm/.local/share/xorg/Xorg.0.log" for additional information. May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) May 09 15:46:58 dyna1.home.front /usr/libexec/gdm-x-session[2572]: (EE) Server terminated with error (1). Closing log file. May 09 15:46:58 dyna1.home.front audit[2574]: ANOM_ABEND auid=4294967295 uid=42 gid=42 ses=4294967295 pid=2574 comm="Xorg" exe="/usr/libexec/Xorg" sig=6 May 09 15:46:58 dyna1.home.front systemd[1]: Started Process Core Dump (PID 2587/UID 0). So maybe this is actually Xorg screwing up (with an ATI card which worked just fine in a span of numerous years). I am attaching the whole /var/lib/gdm/.local/share/xorg/Xorg.0.log. There is a catch, though. This log file starts with "_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root". Both /tmp/.X11-unix and /tmp/.X11-unix/X1024 are owned "gdm gdm". I am think that "infinite loop" reaction on a failures in boot is not really acceptable.
Created attachment 1155472 [details] /var/lib/gdm/.local/share/xorg/Xorg.0.log from a failed boot
This is xorg-x11-server bug after all (see bug #1336521) with an exception of an infinite loop on a failure. Still after downgrade to xorg-x11-server-1.18.3-1.fc25 I am unable to start gdm with Wayland and when it starts then a gnome-session immediately fails and I am immediately back at gdm screen. OTOH with 1.18.3-1.fc25 and X gdm allows me to login in an expected desktop.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.