Description of problem: I manually isolate multi-user.target, then isolate graphical.target, it always fails. If this is a normal boot where it progresses for the first time from multi-user to graphical, it always works. So something is happening when reverting from graphical to multi-user and then back, that causes graphical to fail. This is a regression from Fedora 23 on this hardware, where this problem doesn't happen. Version-Release number of selected component (if applicable): gnome-session-3.20.1-1.fc24.x86_64 xorg-x11-server-Xorg-1.18.3-2.fc24.x86_64 xorg-x11-drv-ati-7.6.1-3.20160215gitd41fccc.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Either clean boot or just log out. 2. Get to a console, tty2 in this case. 3. systemctl isolate multi-user.target 4. systemctl isolate graphical.target Actual results: Several screen flickers of text console tty1, no graphical environment starts, no gdm, just a console with a login prompt (where they keyboard input isn't reflected on scree). I can still switch to tty2 and enter commands. Expected results: I should see gdm/login window and be able to login. Additional info: This system was using Fedora 23 Workstation, and has been upgraded via Gnome Software 3.20 using the new graphical upgrade feature.
Created attachment 1158542 [details] journal_bug1336959.txt journal for this boot. The isolate graphical.target command happens at monotonic time [26073.873794]. Suspicious items: [26074.933133] f23m.localdomain gnome-session[5508]: gnome-session-binary[5508]: WARNING: Error getting login monitor: -13 [26074.933291] f23m.localdomain gnome-session-binary[5508]: WARNING: Error getting login monitor: -13 [26074.933641] f23m.localdomain gnome-session-binary[5508]: WARNING: Lost name on bus: org.gnome.SessionManager [26074.933786] f23m.localdomain gnome-session[5508]: gnome-session-binary[5508]: WARNING: Lost name on bus: org.gnome.SessionManager [26074.945729] f23m.localdomain gnome-session[5508]: Unable to init server: Could not connect: Connection refused [26074.945867] f23m.localdomain gnome-session[5508]: ** (gnome-session-failed:5515): WARNING **: Cannot open display: [26074.949138] f23m.localdomain gdm-launch-environment][5502]: pam_unix(gdm-launch-environment:session): session closed for user gdm [26074.950034] f23m.localdomain gdm[5494]: GdmDisplay: display lasted 0.191156 seconds [26074.951134] f23m.localdomain audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission stop for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' [26074.953959] f23m.localdomain systemd-logind[781]: Removed session c8. [26074.954210] f23m.localdomain gdm[5494]: Child process -5506 was already dead. [26074.954349] f23m.localdomain gdm[5494]: Child process 5502 was already dead. [26074.954472] f23m.localdomain gdm[5494]: Unable to kill session worker process [26074.961462] f23m.localdomain systemd[1]: Received SIGRTMIN+21 from PID 5460 (plymouthd). I never see plymouth or anything graphical during these flickers. [26075.330555] f23m.localdomain /usr/libexec/gdm-x-session[5522]: (EE) RADEON(0): drmmode_do_crtc_dpms cannot get last vblank counter
/etc/gdm/custom #WaylandEnable=false So there must be automatic fallback to X. 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (prog-if 00 [VGA controller]) Subsystem: Apple Inc. MacBookPro8,2 [Core i7, 15", Late 2011] [106b:00e2]
Created attachment 1158543 [details] journal_gdmdebug_bug1336959.txt /etc/gdm/custom.conf [debug] # Uncomment the line below to turn on debugging Enable=true
Non-obvious in the original description is this is Fedora 24 Workstation, i.e. it boots by default in graphical.target. graphical.target -> multi-user.target -> graphical.target The failure is the 2nd transition, from multi-user to graphical.
Same effect here. I'm not using systemd directly, but the legacy commands "init 3 " and "init 5".
(In reply to Chris Murphy from comment #4) > graphical.target -> multi-user.target -> graphical.target > The failure is the 2nd transition, from multi-user to graphical. On F24 PC host p5bse, also with radeon gfx, but with KDM instead of GDM or SDDM, on switch back from multi-user to graphical the greeter appears, but the result of attempting login to a Plasma session instead of a normal session brings up xmessage reporting "Could not start D-Bus. Can you call qdbus?" on a normal F24 splash screen. startx -- :1 from a vtty login produces a normal Plasma session.
Same issue here with Intel Ivy Bridge.
Just dnf distro-sync upgraded from f23 to f24 and X fails to start automatically: This is the only error line in Xorg.0.log: [ 141.948] (EE) RADEON(0): drmmode_do_crtc_dpms cannot get last vblank counter however logging in on console and running startx works ok. I use KDM...
I fixed my issue by doing this: systemctl disable sddm rpm -e sddm sddm-kcm systemctl disable gdm systemctl enable kdm init 3 init 5 And then kdm login screen reappears. Logged in and some KDE stuff started up ok, except there was a dialog box saying "Could not start D-Bus. Can you call qdbus?" and when you hit OK to that, you get logged out. Rebooted, then all good. Looks like the distro-sync didn't re-activate kdm and it reinstalled sddm for some reason (dependencies I assume), and something related to dbus that kdm needs didn't start until I rebooted again. This EE error is still showing in /var/log/Xorg.0.log... [ 141.146] (WW) Option "xkb_variant" requires a string value [ 141.146] (**) Option "xkb_options" "terminate:ctrl_alt_bksp," [ 141.168] (EE) RADEON(0): drmmode_do_crtc_dpms cannot get last vblank counter [ 251.871] (II) RADEON(0): EDID vendor "SAM", prod id 2434 [ 251.871] (II) RADEON(0): Using EDID range info for horizontal sync [ 251.871] (II) RADEON(0): Using EDID range info for vertical refresh [ 251.871] (II) RADEON(0): Printing DDC gathered Modelines: but it seems to be non-fatal, despite the fact that its and EE which is odd. Anyway I'm back in business...
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.