Description of problem: graphical login (gdm?) won't start on "systemctl start graphical.target" Graphical login doesn't occur. Version-Release number of selected component (if applicable): $ uname -a Linux watermelons.emerson.baker.org 3.3.4-5.fc17.i686.PAE #1 SMP Mon May 7 17:37:39 UTC 2012 i686 i686 i386 GNU/Linux $ cat /etc/fedora-release Fedora release 17 (Beefy Miracle) How reproducible: Yes ... in the sense that gdm won't start. Steps to Reproduce: 1. Installed F17 via vnc which gives a "multi-user.target" (was "runlevel 3" behavior) 2. ssh into the box, look around, all is happy. 3. yum update ... 4. systemctl enable graphical.target (fails) 5. systemctl start graphical.target 6. firstboot runs graphically 7. gdm login does not occur. One cannot login to a graphical desktop. 8. sudo pkill Xorg 9. gdm login does not occur. One cannot login to a graphical desktop. 10. goto 7; else goto 11 11. shutdown -r now Upon reboot we're still in multi-user not graphical. The initial install through Step 8 is attachment "messages.1" of /var/log/messages See "Additional Info" Actual results: Boot into multi-user (text console, getty) Expected results: Boot into graphical (desktop login, the fireworks screen). Additional info: Upon reboot the following worked to get to graphical.target ssh into the box from elsewhere... $ systemctl is-enabled graphical.target disabled $ sudo systemctl enabled graphical.target Unknown operation enabled $ sudo systemctl enable graphical.target Failed to issue method call: File exists $ sudo systemctl is-enabled graphical.target disabled $ sudo systemctl start graphical.target <gdm starts > See attachment "messages.2" of /var/log/messages Kernel modesetting graphics seems to be entirely happy. This is a (systemd?) or gdm startup thing. Conclusion: I have graphical.target operating with manual setup.
Created attachment 589137 [details] /var/log/messages #1 as referenced in the initial bug description
Created attachment 589138 [details] /var/log/messages #2 as referenced in the initial bug description
Created attachment 589140 [details] /var/log/messages #1 as referenced in the initial bug description
Created attachment 589148 [details] /var/log/messages #1 as referenced in the initial bug description
Created attachment 589149 [details] /var/log/messages #2 as referenced in the initial bug description
As it may come up ... The machine was configured as: $ ls -l /etc/systemd/system/default.target lrwxrwxrwx. 1 root root 36 Jun 3 12:26 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target To get to a graphical login (runlevel 5) one is supposed to do: $ sudo rm /etc/systemd/system/default.target $ sudo ln -s /lib/systemd/system/graphical.target /etc/systemd/system/default.target $ ls -l /etc/systemd/system/default.target lrwxrwxrwx. 1 root root 36 Jun 4 06:08 /etc/systemd/system/default.target -> /lib/systemd/system/graphical.target I was confused thinking that "systemctl enable graphical.target" did this or should have done this. Perhaps a more helpful diagnostic sequence is indicated here: $ sudo systemctl is-enabled graphical.target disabled $ sudo systemctl enable graphical.target Failed to issue method call: File exists The correct enablement activity is documented in /etc/inittab Boot to gdm login occurs. So what remains it's unclear why gdm won't come up in that first scenario after the firstboot workflow completes.
(In reply to comment #0) > $ sudo systemctl enable graphical.target > Failed to issue method call: File exists Yes, it won't overwrite an existing default.target symlink pointing to a different target. Using "-f" would force it to overwrite. The error message could be improved. As to why gdm did not come up after firstboot, I don't know.
Fedora-18-x86_64-Live-SoaS.iso (RC1) does not startx after firstboot -leaves spinning cursor
(In reply to comment #8) > Fedora-18-x86_64-Live-SoaS.iso (RC1) does not startx after firstboot -leaves > spinning cursor also Fedora-18-i686-Live-SoaS.iso
confirmed in install of RC4 Soas-live x86_64 finishes firstboot but then gdm does not offer a login, only a spinning circle cursor
A new administrator command line switch has been introduced in systemctl , upstream to change the default boot target and get/list the default boot target ( http://cgit.freedesktop.org/systemd/systemd/commit/?id=99504dd4c ) Which should be used and address this issue. Any firstboot/gdm issues should be filed against the correct component if still present.