[gentoo-amd64] Re: KDE/sddm update - all new user accounts crash at login

[Duncan]

Mark Knecht posted on Fri, 08 Apr 2016 10:18:58 -0700 as excerpted:

> I'm traveling on vacation and had an opportunity to update my mom's
> laptop.
> Being that the news about KDE5 plasma becoming standard and needing to
> watch out about app updates in the future not working in KDE4 I decided
> to bite the bullet and get the machine completely updated while I'm
> here. Overall the update process went moderately well - emerge wouldn't
> complete until I removed two packages for blocking issues, but other
> than that KDE5 came up OK ad actually the new plasma stuff seems to make
> things look quite nice on this machine.
>
> One thing I was interested in doing was moving my dad's use to this same
> machine so I did the normal useradd command from the install guide.
> First, I don't know how it was for kdm but with sddm, with it having
> pictures representing each user, sddm doesn't recognize new user
> accounts without being restarted. Once restarted however, my dad's name
> was there, I try to log in, and the whole process goes south with a
> message that plasma has died. If I hit the restart button at that point
> it just does it again and doesn't offer any more options.

First thing, I didn't look it up in the install guide, but did your 
useradd command actually create a home dir for the new user, and do they 
have a password, etc?  Check /etc/passwd and friends (shadow, group and 
gshadow) to see if everything is as it should be.  Also, did the 
"starter" files in /etc/skel/* get copied over to the new user homedirs?

Assuming those basics are now verified correct, as I can imagine 
attempting to login as a new user when that user's homedir doesn't exist, 
or similar, would definitely create problems...


While I'm on kde-plasma5 also, from your description there's very little 
else comparable between that machine and mine.  I don't use a *DM, 
preferring instead to login at the CLI and run startx with the session 
set to kde-plasma5, I won't touch nVidia graphics as they aren't 
freedomware friendly, and my machine doesn't have polkit on it at all 
(solid, a dependency of the kde-plasma5 desktop, in turn runtime-depends 
on udisks:2, which I believe requires polkit, but all that does is turn 
on device insertion and automount functionality, and I prefer manual 
anyway, so I stubbed out the udisks:2 dep with a udisks null-package in 
my overlay that installs no files and has no deps; no more heavy-
dependency udisks to worry about! =:^).  In addition, not only am I on 
~amd64 not stable, but I'm actually running the live-git kde packages 
from the gentoo/kde overlay now.

Like I said, next to nothing the same, including no ssdm installed.  So 
why am I replying?

Simple.  I have a troubleshooting suggestion that is how I'd go about 
narrowing down the problem here, and that I often use for this sort of 
unknown cause problem.  It takes some time and patience, but generally 
works. =:^)

Do you know what the troubleshooting technique called bisecting is?  
That's what I'm suggesting, in a nutshell.

OK, so you know existing users work, and new users don't.

First thing to try:  Copy an existing user's configuration (their entire 
home dir if you don't want to bother trying to figure out what's config 
and what's not at this point) to one of the new user home dirs that isn't 
working.  Of course you'll need to be root to copy cross-user like that.  
Then from the new user's home dir, do a recursive chown of all the files 
you just copied to the new user's username and if different, usergroup.  
If you use chown itself for this, you probably want to use --from= so 
you're only changing files owned by the old user, just in case.  Careful 
with the dotfiles.  You want to chown most of them, but do NOT try to 
do .. as that will recurse upward toward /home and / itself.  (Or just 
use a GUI tool such as mc to do it and pick the files and dirs to chown.)

Now the home dir config should be identical between the two users except 
of course for the ownership.  See if the new user can login now.  If so, 
then you know for sure that the difference is somewhere in the user's own 
home dir config.  If not, then the problem must be somewhere in the 
system level config, because the /home config is the same.

If you find the problem is in the user's home dir (it worked with the old 
user's files), try moving ~/.config and ~/.kde elsewhere (maybe rename 
them to *.test or something) and try again, as that's where most of the 
kde config is at.

If it still works without the old user's .config and .kde dirs, you know 
what's keeping it working isn't in those two dirs, so you can rename half 
of what's left and try again.

If it breaks without .config and .kde, rename just one of them back and 
try again.

Continue the bisection process until you find the "magic" file that's 
allowing the old user to login.  That should give you an idea of where 
the problem is.  If it's a text-based file, you can if you like continue 
bisection from there using a text editor down to the section and line 
that's causing problems.


Meanwhile, if the problem turns out NOT to be in the user's config, 
because with the old user's config copied to the new user and chowned 
accordingly, the new user still can't login, then it should be a system 
config issue.  You can double-check that by temporarily moving the old 
user's home dir elsewhere, recreating it with the files from skel, and 
verifying that the old user can still login, now with a "clean" config.  
If it indeed is something elsewhere in the system, not in the home dir, 
they should still be able to login even with a clean homedir.

Beyond that, you can see if they can login at the CLI instead of from the 
graphical login.

Other than that, I'm not sure what might be wrong at the system level or 
how to go about fixing it, but that bridge can be crossed if we come to 
it, and at least by now you will have eliminated the contents of the 
users home dir and the most basic system config issues as the problem, 
thus vastly narrowing it down from where you were when you first posted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman