Bug#754257: [kdm] Workaround: Started with Empty Home Directory
On Thursday 17 July 2014 11:34:46 Maximiliano Curia wrote:
> Control: priority -1 normal
> Control: tag -1 + moreinfo
>
> ¡Hola David!
>
> El 2014-07-16 a las 14:50 +0300, David Baron escribió:
> > Yes, empty home directory for user and it logs in. Any data, of course,
> > can be brought in from the saved copy.
>
> Let's make a summary so far:
> * You have at least one user in your system that fails to log in using kdm.
> * In the same system you have other users that do work correctly. * With a
> new user the session starts correctly.
>
> I couldn't find in the reports what kind of session you are trying to start
> with the users that can't login, I'm assuming you are trying to start kde
> plasma.
>
> With this information, I would suspect of a composite/opengl related issue,
> and of some corrupted data in the home user directory that causes the
> session to fail completely.
>
> Please respond as clearly as possible the questions bellow:
>
> You mentioned that the bug doesn't happend with your user, which makes me
> wonder if you are loging in your user in the first graphical session and the
> failling users are trying to log in in the secondary graphical sessions
> (Change users/ New Login in kde). Can you confirm me if you log the
> failling user in the first graphical session if it works or not?
Both users now work, second user started with new, empty home directory. It
did NOT make any difference whether it was a primary or secondary login. When
it still did not work, did not. Does work, does...
>
> Does the session of the failling users start correctly using another display
> manager (lightdm, gdm, etc)?
Was not tried. Posters on other forums said gdm worked when kdm did not. These
were not Debian posters. lightdm is Ubuntu
>
> Does the session starts correctly if you use another type of session/desktop
> environment/window manager (like openbox, for example)?
Did not try other graphical sessions. I could log the user onto a bash shell.
>
> After replying these questions, a good way to find the culprit would be to
> do a binary search with the data in the home user. It would be particularly
> useful if you could reproduce the issue copying a failling user ~/.kde and
> ~/.config to a newly created user home.
I no longer have them, no important data. However, when it did fail, old or
blank or no .kde made no difference. Problem was outside of .kde directory.
One other hint. My session which I got working with dist-upgrade started with
a fresh (no) .kde. However, the menus that I had were the old menus from
previous installation. So maybe something outside of .kde, in .config or
wherever the menu info is stored.
Reply to: