Bug 1337546

Odd, of kdm was enabled previously, then kdm should still be enabled, what does this say?


systemctl status kdm

I guess it may be too late to check that, re-reading your comment(s), you already enabled lightdm, which in effect, would disable all other display managers (I believe).

When you say " I had both lightdm and kdm installed but both were disabled", how did you check exactly?   
systemctl status lightdm
systemctl status kdm

or some other way?


Another possibility: kdm was enabled, but was crashing or otherwise not starting properly after the upgrade.

(In reply to Rex Dieter from comment #2)
> I guess it may be too late to check that, re-reading your comment(s), you
> already enabled lightdm, which in effect, would disable all other display
> managers (I believe).
> 
> When you say " I had both lightdm and kdm installed but both were disabled",
> how did you check exactly?   
> systemctl status lightdm
> systemctl status kdm
> 
> or some other way?
> 
> 
> Another possibility: kdm was enabled, but was crashing or otherwise not
> starting properly after the upgrade.

When it landed at the text console I did:

systemctl list-unit-files | grep dm

and it showed both kdm and lightdm as disabled.

In my current state:
[root@dgilbert-t530 dgilbert]# systemctl status kdm
● kdm.service - The KDE login manager
   Loaded: loaded (/usr/lib/systemd/system/kdm.service; disabled; vendor preset:
   Active: inactive (dead)

I can go back through the logs with journalctl; since I'm still in my 1st f24 boot (in which I had no display manager):

[root@dgilbert-t530 dgilbert]# journalctl -b 0 -u kdm
-- No entries --

so I don't think it crashed (and I don't see anything in abrt-cli ls from today)

Then -1 I think is the system-upgrade boot:
[root@dgilbert-t530 dgilbert]# journalctl -b -1  -u kdm
-- Logs begin at Mon 2013-12-09 16:12:48 GMT, end at Thu 2016-05-19 15:02:08 BST
May 19 12:02:37 dgilbert-t530 systemd[1]: Stopped The KDE login manager.

In what I think was the last normal boot of f23 I see:
[root@dgilbert-t530 dgilbert]# journalctl -b -2  -u kdm
-- Logs begin at Mon 2013-12-09 16:12:48 GMT, end at Thu 2016-05-19 15:03:10 BST
May 19 10:11:28 dgilbert-t530 systemd[1]: Started The KDE login manager.
May 19 10:11:28 dgilbert-t530 systemd[1]: Starting The KDE login manager...
May 19 10:11:28 dgilbert-t530 kdm[1249]: plymouth is running
May 19 10:11:28 dgilbert-t530 kdm[1249]: plymouth is active on VT 1, reusing for
May 19 10:11:28 dgilbert-t530 kdm[1249]: plymouth should quit after server start
May 19 10:11:29 dgilbert-t530 kdm[1249]: Quitting Plymouth with transition
May 19 10:11:29 dgilbert-t530 kdm[1249]: Is Plymouth still running? no
May 19 11:38:08 dgilbert-t530 kdm[1249]: plymouth is NOT running
May 19 11:38:08 dgilbert-t530 systemd[1]: Stopping The KDE login manager...
May 19 11:38:08 dgilbert-t530 systemd[1]: Stopped The KDE login manager.

Strange, I've no idea how kdm service could have gotten disabled in the upgrade process.  It certainly is not intended.

I'll triage this to kde-workspace (owner of kdm) for now, pending further investigation.

Proposed as a Freeze Exception for 24-final by Fedora user rdieter using the blocker tracking app because:

 Folks using kdm and upgrading to f24 currently end up with kdm being disabled.  I *think* I know the cause, and if I'm right, the fix will need a freeze-exception to be included in GA release (an update can't fix it)

adjusting summary to match symptoms

Had same problem after upgrade on two systems. However, I was running KDE with SDDM. Fixed with "systemctl enable sddm.service" and a reboot. So whatever the problem is with upgrade procedure, it is the same with kdm and sddm.

+1
No KDM after upgrading to Fedora 24.

This may be somehow caused by https://bugzilla.redhat.com/show_bug.cgi?id=1349664 , though on a quick look, the sddm spec file uses %systemd_post , which should result in this:

if [ $1 -eq 1 ] ; then 
        # Initial installation 
        systemctl --no-reload preset sddm.service >/dev/null 2>&1 || : 
fi 

so it shouldn't run on an upgrade...

*** Bug 1349855 has been marked as a duplicate of this bug. ***

rex: i'm not really convinced this *is* caused by 1349664, at least not yet, I don't entirely see how it could be, unless you know of something else that would re-load the preset on upgrade.

OK, my only other theory is that the problem here is because the package providing kdm.service changed

f23: kde-settings-kdm
f24: kdm-settings

and on upgrade (with Obsoletes) the %postun scriptlet from kde-settings-kdm (effectively) disables it.

This may be fixable with a %trigger, I'll try to investigate more soon.

I also saw the same behavior on the two machines I upgrade (one from F23, the other directly from F22). Like the original report, I upgraded via dnf system-upgrade. Unlike the original report, kdm was the only display manager I have installed.

Just ran into this right now after upgrading from F23 to F24.

*** Bug 1403730 has been marked as a duplicate of this bug. ***

I have the same problem when switching from fedora 23 to fedora 24.
The GUI is not working.
kdm service was in the status of disabled.

I turn it on command
systemctl enable kdm
Problem solved.

I assume that the script is not finished with the update.

===== RUS ========================================================
У меня такая же проблема при переходе с fedora 23 до fedora 24.
GUI не работал.
kdm сервис был в статусе отключен.

Я его включил командой
systemctl enable kdm
Проблема решена.

Предполагаю что не доработан скрипт при обновление.

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.