Bug 828197

Summary: systemctl start graphical.target => finishes firstboot but then gdm does not offer a login, only a spinning circle cursor
Product: [Fedora] Fedora Reporter: Wendell Baker <wendellcraigbaker>
Component: systemdAssignee: systemd-maint
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: johannbg, metherid, mschmidt, msekleta, notting, plautrba, satellitgo, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-15 16:05:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/messages #1 as referenced in the initial bug description
none
/var/log/messages #2 as referenced in the initial bug description
none
/var/log/messages #1 as referenced in the initial bug description
none
/var/log/messages #1 as referenced in the initial bug description
none
/var/log/messages #2 as referenced in the initial bug description none

Description Wendell Baker 2012-06-04 12:48:01 UTC
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.

Comment 1 Wendell Baker 2012-06-04 12:49:01 UTC
Created attachment 589137 [details]
/var/log/messages #1 as referenced in the initial bug description

Comment 2 Wendell Baker 2012-06-04 12:51:33 UTC
Created attachment 589138 [details]
/var/log/messages #2 as referenced in the initial bug description

Comment 3 Wendell Baker 2012-06-04 12:52:38 UTC
Created attachment 589140 [details]
/var/log/messages #1 as referenced in the initial bug description

Comment 4 Wendell Baker 2012-06-04 12:57:53 UTC
Created attachment 589148 [details]
/var/log/messages #1 as referenced in the initial bug description

Comment 5 Wendell Baker 2012-06-04 12:58:31 UTC
Created attachment 589149 [details]
/var/log/messages #2 as referenced in the initial bug description

Comment 6 Wendell Baker 2012-06-04 13:15:35 UTC
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.

Comment 7 Michal Schmidt 2012-06-04 14:59:33 UTC
(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.

Comment 8 satellitgo 2013-01-06 18:56:22 UTC
Fedora-18-x86_64-Live-SoaS.iso (RC1) does not startx after firstboot -leaves spinning cursor

Comment 9 satellitgo 2013-01-06 18:57:53 UTC
(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

Comment 10 satellitgo 2013-01-10 06:00:11 UTC
confirmed in install of RC4 Soas-live x86_64 
finishes firstboot but then gdm does not offer a login, only a spinning circle cursor

Comment 11 Jóhann B. Guðmundsson 2013-06-15 16:05:23 UTC
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.