Created attachment 116704 [details] uncompressed flat file from /var/log SUMMARY startx with .xinitrc containing startkde fails to show a desktop. I have NO idea where this bug really belongs because KDE appears to be stuck somewhere in it's initialization processing. This is a Fedora 30 x86_64 distribution. kde-workspace-common-4.11.22-23.fc29.noarch is as close as I can come to where the problem possibly exists. Are there other files you need to see? STEPS TO REPRODUCE 1. startx 2. 3. OBSERVED RESULT Splash screen appears with a small circle chasing itself. Finally this ends and a blank screen appears. The mouse works and displays a cursor-pointer but NOTHING else appears. Is there a hidden trick to get kde to show more of what it's doing? What processes should be running when kde is behaving "normally"? Is there a log other than Xorg.0.log? /var/log/messages shows nothing. EXPECTED RESULT a fully operational kde desktop SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: kf5-plasma-5.52.0-2.fc30.x86_64 (available in About System) KDE Plasma Version: KDE Frameworks Version: kf5-frameworkintegration-5.52.0-1.fc30.x86_64 Qt Version: qt5-qtenginio-1.6.2-19.fc30.x86_64 ADDITIONAL INFORMATION
What about with a display manager?
David, I'm not sure what you mean by "Display Manager". Can you elucidate please? My knowledge of KDE doesn't go much deeper than having .xinitrc contain "startkde" and my issuing a startx command. I have done some minor configuration changes with the "systems manager" tool... Most of these changes are what I would call tweaks. George...
Something like SDDM / LightDM. Use outside of that is possible, but a failure there typically indicates end user setup problems rather than an upstream bug. If you have an issue whilst using a display manager please reopen. SDDM will store it's logs of the session in ~/.local/share/sddm/xorg-session.log please attach that if you still have issues.
David, The default display manager worked... I went back to trying to startkde and gave up in disgust... left it with a working mouse pointer and an otherwise black screen. Came back about an hour later and kde was now displaying a desktop. I noticed some tweaks that I missed earlier and attempted to correct them. System settings had other ideas though. "Global Shortcut daemon" was not running. Several other items seemed to put system settings in a loop. Clearly there seems to be some kde components that are not running. I've included the output of the ps command... if you could identify what's missing and how to start them or troubleshoot them. Thanks for your help, George...
Created attachment 116709 [details] uncompressed flat file containing output from the ps command.
I had a look, couldn't seen anything major. I suggest comparing envs of the display manager session, that's the main thing they're responsible for setting up correctly. Anything else is outside the scope of our bug tracker, sorry.
Hi, This problem still seems to exist, even with an OUT OF THE BOX FC31 system AND no other modifications of any kind. Is someone working this problem? If not, what do I need to do to get some action on this from the KDE folks? Please help, George...
>The default display manager worked... > even with an OUT OF THE BOX FC31 system These messages are conflicting. Can you clarify please.
David, Thanks for your response. Up to the FC30 system, KDE was working fine... startup took less than 2 minutes. Along came FC30... Start up times > 30 minutes... and longer. The problem is that I got disgusted after 10-20 minutes and went to get lunch... an hour (or more) later there was a KDE screen. Not what I would call the best of circumstances. My latest results show that no matter how long I wait, nothing appears. This is on a freshly installed FC31 system with NO user mods and using SDDM. It's like some component of KDE has made a request of some other component that is not responding or isn't running. Using run level 3, the startx, and .xinitrc I executed the startkde script with "-xv" flags, "/usr/bin/bash -xv /usr/bin/startkde" and recorded the results. With all the clutter, I'm not able to determine what has failed or stopped responding. It would be VERY useful to know just what's supposed to be running. It would be VERY useful to be able to restart failed components to possibly do some debugging? I'm willing to give whatever help I can give to get this problem resolved. The bug report at "https://bugs.kde.org/show_bug.cgi?id=380495" looked like a good match to the symptoms that I'm seeing so I added my info to that report. What can I do to help get this problem resolved? As it is now, KDE is NOT usable. George...
David, I have reinstalled several older versions of Fedora Core (27, 29, 31) in a virtual environment (VirtualBox). FC27 and FC29 seem to be working well... even with the startx and .xinitrc changes. I have been working on the Fedora Core 31 virtual machine by applying package installations "dnf install '*xorg*' and other "normal" upgrades but still no joy (WITH NOMODESET installed). I have removed the "nomodeset" kernel command-line parameter and am seeing a more or less "normal" response to the startx & .xinitrc setup. All these Fedora Core systems worked with "SDDM". As I understand it, "nomodeset" turns off the kernel level hardware support for the video card. Here's what one site says "https://askubuntu.com/questions/716957/what-do-the-nomodeset-quiet-and-splash-kernel-parameters-mean": The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts.. This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesn't work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded. Have you seen anything in the KDE code that might depend on the setting of "nomodeset"? Regards, George...
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
It's late... I don't see what info is needed. Can you tell me the comment number where the request is made please? In any event, I have info to submit here: 1) This bug continues to exist with "NOMODESET" in the kernel boot parameters. 2) With my profile active AND .xinitrc the bug seems to exist. 3) KDE is now working. "currently", nomodeset is NOT set and .xinitrc is NOT present... KDE startup executes seemingly correctly in a reasonable amount of time. The freeze is gone. 4) I'm trying to isolate where the problem occurrs. I will post here when/if I discover something. Thanks, George...
The question is if this issue is reproducible with a stock LiveDVD, or if this is the result of some customization.
Christoph, Thanks for your response AND your question. I have tried several of the .iso images provided by the Fedora project (fc27, fc28, fc29, fc31). I implemented the "nomodeset" change and "my" .xinitrc file with NO problems up to fc31). The problem seems to have started with fc30 which I gave up on in favor of fc31 (rawhide). I have responded with several comments 4, 7, 10 and 12. I am currently running a FC31 system with KDE et. al. at their "current/latest" version(s). I'll add a list of all(?) my kde components to this upgrade. What do you mean by "stock liveCD"? Only one provided by KDE.org? Given my current status, I don't think a out of the box liveCD would show/prove anything. It seems to me that comment 12 and possibly 10 show where I am at this point but I'll summarize with my latest state/info since I do have an update: Current system is FC31 (rawhide). nomodeset is active in the kernel commandline at boot. The startx command works just fine (I'm at runlevel 3 (NO DM active). my .xinitrc is NOT active (I disabled it as part of a debugging effort). To get to this state I disabled all "my" modifications and put them back one at a time. So far, no problems. My next step is to activate my .xinitrc which contains ONLY a "/usr/bin/bash -xv /usr/bin/bash/startkde" command. All these hoops seem to point out the need for something from KDE.org to query all KDE "services or daemons" that should be running AND verify their status (i.e., running). Possibly, some way to start inactive/broken services. Some way to turn on a global and/or individual logging activity within the KDE components. This would help the debugging effort immensely. I will post the results of this change later today. Thanks again for your attention to this problem. George...
Created attachment 119511 [details] flat file containing all "kde" rpms and their "current" levels Thank you VERY MUCH for your help/interest/support/WAY COOL CODE. George...
I'm hoping that this post will resolve the needs info flag on this bug.
fyi, fedora 31, aka rawhide, is a development platform, I would advocate not using that unless you have the interest/aptitude to debug things yourself. Otherwise, strongly advice sticking with stable releases (f29 or f30 at this point)
Rex, I am interested in contributing to the rawhide releases. I don't know enough to do much debugging on my own though. For the most part, I work well with developers... forming a team of sorts. I am more than willing to work with developers to resolve these kinds of problems... WHEN they are willing. I have a rather long history of systems administration type work (about 50 years) and have been a developer in the past. I like working with developers... I learn with EVERY experience and I like to think that they learn too. Thanks for all your input! George...
Sure but... in my experience, the problems described here are likely not kde-related. More likely it is an issue with video drivers (possibly related to the use of nomodeset, which is generally not recommended), where X simply does not start at all.
I hear what you're saying. In attempting to isolate the problem I have found (I think) shortcomings in the code. Things like turning on debug mode with kde et. al., identifying the necessary parts of kde that should be running but aren't, the need for a better logging system, the ability to turn on/off debug for kde components and/or starting/restarting kde components. Some/all of these would have gone a long way towards identifying where the problem happens and why. As it is now, I'm back to using "nomodeset" with NO problems with kde. The only thing left is to activate the .xinitrc in "my" home directory. Clearly something has changed but what? I REALLY do appreciate your (and others) time and energy spent in working this bug.