KDE/sddm update - all new user accounts crash at login

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

KDE/sddm update - all new user accounts crash at login

Mark Knecht
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.

For context this is an Asus G73JW laptop, completely stable except for one package that emerge made me add use flags and needing to downgrade to nss-3.20.1 to run chrome. The kernel is 4.1.15-gentoo-r1 and it's running nvidia-drivers-361.28.

I do not see any problems in sddm.log. 

Looking in /var/log/messages I'm finding two segfaults that don't occur when using accounts that previously existed:

Apr  8 09:50:01 Rosie cron[6140]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Apr  8 09:50:03 Rosie acpid[2307]: client 5798[0:0] has disconnected
Apr  8 09:50:15 Rosie acpid[2307]: client connected from 5798[0:0]
Apr  8 09:50:15 Rosie acpid[2307]: 1 client rule loaded
Apr  8 09:50:23 Rosie acpid[2307]: client 5798[0:0] has disconnected
Apr  8 09:50:54 Rosie kernel: kactivitymanage[5919]: segfault at 7f093deb5c50 ip 00007f0928376071 sp 00007ffe78b30568 error 4 in libQt5Sql.so.5.5.1[7f0928362000+3f000]
Apr  8 09:50:56 Rosie polkitd[2423]: Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session8 (system bus name :1.84, object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Apr  8 09:50:56 Rosie kernel: nvidia-modeset: Freed GPU:0 (GPU-ae014ee7-c17d-72a3-aa35-2dcd7c3050cf) @ PCI:0000:01:00.0
Apr  8 09:50:56 Rosie kernel: traps: ck-remove-direc[6248] trap int3 ip:7fdc33ff7313 sp:7ffea9594a20 error:0
Apr  8 09:50:56 Rosie kernel: ACPI Warning: \x5c_SB_.PCI0.PEG3.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150410/nsarguments-95)
Apr  8 09:50:56 Rosie kernel: ACPI Warning: \x5c_SB_.PCI0.PEG3.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150410/nsarguments-95)

The kernel trap appears to be related to consolekit. The libQt5Sql reference is from qtsql-5.5.1

Rosie ~ # equery belongs /usr/lib64/libQt5Sql.so.5.5.1
 * Searching for /usr/lib64/libQt5Sql.so.5.5.1 ... 
dev-qt/qtsql-5.5.1 (/usr/lib64/libQt5Sql.so.5.5.1)
Rosie ~ #

Rosie ~ # locate ck-remove-direc
/usr/lib64/ConsoleKit/ck-remove-directory
Rosie ~ 

I can Alt-Ctrl-F1 to a console and restart xdm just fine. Any attempt to log into any new account results in the same crash. After restarting xdm I can log into any account that existed before the update but no new accounts work so far.

Also, not a show stopper but if I boot the machine, switch to the console and come back to sddm the screen is corrupted but works. The date & time are gone, the pulldown in the upper left no longer says plasma, and some other text is missing or corrupted. sddm on this machine is not really ready for prime time.

Any ideas where to look or what to try to get new accounts working? If I need to post more info please let me know. I wanted to capture this much and then go back to looking.

It is currently Friday morning. I hope to solve this before Tuesday evening when I lave.

Thanks,
Mark
Reply | Threaded
Open this post in threaded view
|

Re: KDE/sddm update - all new user accounts crash at login

Duncan-42
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


Reply | Threaded
Open this post in threaded view
|

Re: KDE/sddm update - all new user accounts crash at login

Mark Knecht


On Sat, Apr 9, 2016 at 1:58 AM, Duncan <[hidden email]> wrote:

>
> 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...
Hi Duncan,
   Thankfully, after returning the next day, doing another eix-sync and building
a few more packages it started working. I have no explanation at this point for
the plasma crashes but as they no longer occur I guess for now it's 'event over,
moving on'.
  
   I appreciate your inputs.

Cheers,
Mark
Reply | Threaded
Open this post in threaded view
|

Re: KDE/sddm update - all new user accounts crash at login

Duncan-42
Mark Knecht posted on Sun, 10 Apr 2016 11:32:43 -0700 as excerpted:

> Thankfully, after returning the next day, doing another eix-sync and
> building a few more packages it started working. I have no explanation
> at this point for the plasma crashes but as they no longer occur I guess
> for now it's 'event over, moving on'.

Cool beans! =:^)

--
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