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
