Bug 1625948

Summary: systemctl set-default graphical.target doesn't effective
Product: [Fedora] Fedora Reporter: xhe <xhe>
Component: systemdAssignee: systemd-maint
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 31CC: jkucera, lnykryn, msekleta, sgrubb, s, systemd-maint, tmraz, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-01 13:57:13 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
boot.log
none
dmesg.log none

Description xhe@redhat.com 2018-09-06 09:25:31 UTC
Created attachment 1481242 [details]
boot.log

Description of problem:
systemctl set-default graphical.target doesn't effective and work, I have to start X by manual everytime on fedora 27

Version-Release number of selected component (if applicable):
$ cat /etc/redhat-release 
Fedora release 27 (Twenty Seven)

$ uname -r
4.17.19-100.fc27.x86_64

$ rpm -qa|grep usermode
usermode-1.112-3.fc27.x86_64

How reproducible:
often

Steps to Reproduce:
1. Install fedora 27
2. upgrade system to the latest with dnf or yum
3. system lost the X after boot up

Actual results:
X can NOT work after system boot up, I have to executed 'startx' every time. I checked the boot.log and dmesg, I didn't see any ERROR or FAIL there.

Expected results:
X is not started automatically

Additional info:

Comment 1 xhe@redhat.com 2018-09-06 09:26:35 UTC
Created attachment 1481243 [details]
dmesg.log

Comment 2 Ben Cotton 2019-08-13 16:57:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 3 Ben Cotton 2019-08-13 19:44:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 4 Jiri Kucera 2019-12-03 14:36:11 UTC
It looks like that the affected component is systemd, but I am not 100% sure about it. usermode just provides userhelper program which allows configured programs to be run with superuser privileges by ordinary users (it is a predecessor of polkit/D-Bus).

Comment 5 Zbigniew Jędrzejewski-Szmek 2019-12-03 16:33:42 UTC
Dunno, why do you think it's not effective? What does 'systemctl get-default' say?

Note that the attached boot.log is from an unfinished boot, so not everything
that has been queued to be started was started at the time the log ends.