I'm on Kubuntu 15.04. Yesterday I picked up my laptop and the power cut out. After re-starting, when I logged in, the normal K loading screen started, and then stopped at about 70%, and the blue bar didn't move any further. The desktop did finish loading, because I heard the sound of skype starting, and got a visual notification over the top of the loading screen from yakuake, but I couldn't do anything, because the loading screen was covering the desktop (as far as I could see). Eventually I got a working computer back by logging in to a console and installing XFCE, and logging in to that. However, I'd like to return to KDE if possible.

I already tried a few things to see if I could get in. I tried restarting plasmashell but the loading screen remained. I could kill sddm, and that would take me back to the login prompt. I tried moving .kde, .config/kde* and .config/plasma* out of the way and restarting, no difference. I tried re-installing a number of components of kde (kwin, plasma-shell, etc), thinking that maybe a system file had been corrupted, but that didn't help.

If anyone has any ideas of what I might try to kill the loading screen after loading, let me know. May there's a particular package related to that screen that I can try reinstalling?

Does anyone know when the next release of KDE packages is likely to occur via the ubuntu repos? Perhaps an upgrade would fix what ever is occuring.

Log in as far as possibe, then press "SHIFT+Alt+F12" - if the logon sound plays you'll have logged in but the compositor doesn't paint.
If the above works, see whether you can resume the compositor afterwards (same shortcut) and on success, post (in code tags!) the output of "qdbus org.kde.KWin /KWin supportInformation"

Sorry, I forgot to mention that I have also already tried alt+shift+f12. No luck, it didn't change anything.

Is it possible to use a different login manager, perhaps?

It's unlikely related to the login manager.

> I picked up my laptop and the power cut out

Does that mean the machine powered down immediately?
In case, you might face stale lockfiles, corrupted cache or - if ubuntu was just running an update - even broken libraries.

The most basic test would be to get rid of you cache: "rm -rf ~/.cache"

Yeah, powered down immediately.

I tried clearing ~/.cache. No difference. Are there system cache files that I should try clearing too? Anything in /var/cache/?

Is it possible to change back to lightdm instead of sddm? Maybe that might make a difference?

> Is it possible to change back to lightdm instead of sddm?
Yes.

> Maybe that might make a difference?
No. The DM just starts a session executable and then waits. It's at that point no longer responisble for anything.

Second try is to log in with a new user, if that fails as well, try "apt-get update; apt-get upgrade".

The power loss probably screwed some file - it's just whether it's something of your user or a system library (half installed package etc.)

Already tried a full upgrade. No joy. I upgrade regularly though, so not many packages were in need of an upgrade.

So, oddly enough, I can log in to KDE fine with a new user. After that, I tried again to log out, move all of the ~/.kde , ~/config/plasma* and ~/config/kde* files, as well as deleting the cache, and then tried logging in again. Same problem. Maybe I'm missing a file that should be removed? Or maybe there is some system file that keeps track of users? or something in /tmp/?

~/.config/k* - i'd first bet on ~/.config/ksmserverrc - might also be kdedrc or kconf_updaterc

luebking wrote:~/.config/k* - i'd first bet on ~/.config/ksmserverrc - might also be kdedrc or kconf_updaterc

YAAAAAASSS!! I got in. One of those did it. Which one, I suppose I'll never know. Thanks for the persistence leubking!

Now to migrate all of my old KDE app configs back in. Sometimes I really wish k* apps weren't so tighly integrated with kde. It'd be nice to know that I could just delete ~/.kde and not have to worry about losing accounts and data in konversation/kmail/kopete/okular/etc.

Hint: bisect.
Move half the configs back. If everything's fine, go on the the half of the remaining. If not, remove half of the last moved in configs again. This allows you to pretty fast get to the offending files (log(n))

luebking wrote:Hint: bisect.
Move half the configs back. If everything's fine, go on the the half of the remaining. If not, remove half of the last moved in configs again. This allows you to pretty fast get to the offending files (log(n))

Sure. Bisection is nice, but the log(n) is pretty irrelevant when it's the moving files and restarting that takes all of the time (sure, I might finish in 7 steps, but if it takes half an hour each time, that's a huge pain). Anyway I don't care about 95%+ of the stuff in .kde or .config/plasma* etc., just a few files and folders related to a particular app. But it is not at all clear what some of those files are for, or whether they're related to some content storage that I actually use. Anyway, I'll keep the moved version for a while, in case I missed migrating some data back in. If app-related content was always stored in .config/app/, and not in .kde/share/(app|config?), then it'd be safe to just nuke .kde every time (since it'd just contain non-important theme/cache/DE config that would be easy to regenerate).

Ah, I see, you were probably just talking about the "I suppose I'll never know" part. Yes, fair call. I probably should have kept a copy of those files, but I figured they didn't contain any personal data, so were probably not important to keep.

I guess if it happens again, I'll target some of those first, and see if I can post an appropriate bug report. But I suspect the occurrence of this is incredibly low, and it's probably better to just deal with individual cases. Although a sanity check on corrupted files that might do this would be a nice feature.