[opensuse] 15.1, plasma desktop doesnt load any more for certain user
Hi openSUSE list, I had a post with no replies on support suse list: <https://lists.opensuse.org/opensuse-support/2020-01/msg00123.html> meanwhile I have discovered that this test machine has come rather a longer way with upgrades from previous opensuse releases. Everything worked fine until a few weeks ago. With some zypper dup update, a normally working plasma desktop user was unable to log into plasma ever after. Some extra local linux user accounts, whom had never used the gui login before and thus not created any plasma related config files and never logged into plasma, tried yesterday, still work fine and happily log into plasma. plasma for these users looks rather new and the menu looks more stylish than I remember it from that other user that is currently blocked from logging into plasma. Maybe as that older user has used plasma for a long period of time. Anyhow, how would I make that one blocked user be able to login into plasma again? what config files can I look at, edit or whatever I need to do? I dont have actual real personalisation or specials for that user, only some xterm or konsole was running and always been restoring upon logon to that plasma desktop, thats basically all. IceWM and KWM or those simplistic desktops do work for that plasma affected user as well. Help? TY. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op woensdag 29 januari 2020 13:04:04 CET schreef cagsm:
Hi openSUSE list,
I had a post with no replies on support suse list: <https://lists.opensuse.org/opensuse-support/2020-01/msg00123.html>
meanwhile I have discovered that this test machine has come rather a longer way with upgrades from previous opensuse releases.
Everything worked fine until a few weeks ago. With some zypper dup update, a normally working plasma desktop user was unable to log into plasma ever after.
Some extra local linux user accounts, whom had never used the gui login before and thus not created any plasma related config files and never logged into plasma, tried yesterday, still work fine and happily log into plasma. plasma for these users looks rather new and the menu looks more stylish than I remember it from that other user that is currently blocked from logging into plasma. Maybe as that older user has used plasma for a long period of time.
Anyhow, how would I make that one blocked user be able to login into plasma again? what config files can I look at, edit or whatever I need to do? I dont have actual real personalisation or specials for that user, only some xterm or konsole was running and always been restoring upon logon to that plasma desktop, thats basically all.
IceWM and KWM or those simplistic desktops do work for that plasma affected user as well. Help? TY. That's probably some old plasma (widget) config. Move all ~/.config/plasma* stuff somewhere else, then try again.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jan 29, 2020 at 1:13 PM Knurpht-openSUSE <knurpht@opensuse.org> wrote:
That's probably some old plasma (widget) config. Move all ~/.config/plasma* stuff somewhere else, then try again.
Thanks for this hint, unfortunately this didnt help. the mouse cursor stil sits there after the circle animation stops after a while. I have removed all the plasma* files from my users ~/.config/ directory I have looked around in a text console in that home directory/.conf/ and lot of rc-named files are there from exactly december 19th 2019, thats most likely the day the plasma/desktop stuff stopped working for this users account. the only plasma* file that gets generated with a very simple english locale definition or something is in ~/.config/ again after I try to log-in with this affected user. The four or five other files also named plasm* dont come back yet as no successful login has happened just yet. Any more hints? TY. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 29 Jan 2020 14:02:35 +0100, cagsm wrote:
On Wed, Jan 29, 2020 at 1:13 PM Knurpht-openSUSE <knurpht@opensuse.org> wrote:
That's probably some old plasma (widget) config. Move all ~/.config/plasma* stuff somewhere else, then try again.
Thanks for this hint, unfortunately this didnt help. the mouse cursor stil sits there after the circle animation stops after a while. I have removed all the plasma* files from my users ~/.config/ directory
I have looked around in a text console in that home directory/.conf/ and lot of rc-named files are there from exactly december 19th 2019, thats most likely the day the plasma/desktop stuff stopped working for this users account.
the only plasma* file that gets generated with a very simple english locale definition or something is in ~/.config/ again after I try to log-in with this affected user. The four or five other files also named plasm* dont come back yet as no successful login has happened just yet.
Any more hints? TY.
Try to remove the user related plasma-session files from /tmp (if there is any). Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-29 07:04 AM, cagsm wrote:
Anyhow, how would I make that one blocked user be able to login into plasma again? what config files can I look at, edit or whatever I need to do? I dont have actual real personalisation or specials for that user, only some xterm or konsole was running and always been restoring upon logon to that plasma desktop, thats basically all.
Sometimes the best solution is to simply recreate the desktop from scratch. This means deleting anything desktop and then logging in. You might even take is so far as to delete & recreate the user, backing up their files first. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jan 29, 2020 at 4:20 PM James Knott <james.knott@jknott.net> wrote:
Sometimes the best solution is to simply recreate the desktop from scratch. This means deleting anything desktop and then logging in. You might even take is so far as to delete & recreate the user, backing up their files first.
Heck this is a pity :( I even deleted pretty mich everything in that.config/ directory, now all those *rc files and whatnot are all from januar 2020 today. I even went back up to the ~/ and removed lots of stuff there in various dot directories, caches, but this user still does not log into plasma succesfully. Certainly, there must be some way to monitor the file progress during such events as login etc, but I am not very fluent in this kind of matter. Any hints on how to really debug this issue? :( TY. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/29/2020 07:52 AM, cagsm wrote:
On Wed, Jan 29, 2020 at 4:20 PM James Knott <james.knott@jknott.net> wrote:
Sometimes the best solution is to simply recreate the desktop from scratch. This means deleting anything desktop and then logging in. You might even take is so far as to delete & recreate the user, backing up their files first.
Heck this is a pity :( I even deleted pretty mich everything in that.config/ directory, now all those *rc files and whatnot are all from januar 2020 today. I even went back up to the ~/ and removed lots of stuff there in various dot directories, caches, but this user still does not log into plasma succesfully. Certainly, there must be some way to monitor the file progress during such events as login etc, but I am not very fluent in this kind of matter. Any hints on how to really debug this issue? :( TY.
This is a long shot, but I've had it happen to me on multiple occasions. From the user's home directory do a "ls -la" and check the owner and group of these two directories: .config .dbus If the owner and group are "root" "root" this could be the problem. To fix just do a "chown -R username.users .config .dbus". Of course, use the real username. Hope this helps. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jan 29, 2020 at 5:07 PM Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
This is a long shot, but I've had it happen to me on multiple occasions. From the user's home directory do a "ls -la" and check the owner and group of these two directories: .config .dbus If the owner and group are "root" "root" this could be the problem. To fix just do a "chown -R username.users .config .dbus". Of course, use the real username.
No too bad but thanks for trying, those two folders and all the subfolders and files in them are properly assigned to testusername:users here. Thats all right. What I observed in addition was a 100% cpu consuming task called kwin_x11 that had been eating/runnin at over 3000 time units, dont know what top column had shown as time units, well whatever this machine has 41days uptime, and its maybe with 4 cpu cores could end up at around those 40days or something of cpu sonumption of that process. But I killed it forefully, now everything is basically idle again but this didnt help either to login the test user. Is there some logging facility of the logon or plasma loading process, where I could read something? Is it possible that maybe the desktop before showing is waiting for some external devices, mount points or something? usb keys, usb disks or such stuff? I have some useful data in the users home directory and I dont really have the time right now to clean up or decide which files and structures I could need and could be moved and which can be deleted to be able to recreate the complete users home dir? or the user as whole? this is some very basic setup, the userid is 1000 and basically the first user that has been added to this machine like long time ago. Dont know why this needed to be messed up this badly. Basically I only do zypper up or autoupdate, and never mess with packages or anything. Its a real pitty that opensuse in this terms behaves much worse than any windows platform I ever came across to. Meaning destroying very basic functionality and all defaults vanilla vendor set stuff :( I am only an end user mostly. And I very much stay away from deliberately mess with configs packages files or such stuff. Especially the desktop things. Maybe this is also a reason why linux desktop hasnt took off so far? ;) Seriously, this is really immensely annoying. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* cagsm <cumandgets0mem00f@gmail.com> [01-29-20 11:28]:
On Wed, Jan 29, 2020 at 5:07 PM Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
This is a long shot, but I've had it happen to me on multiple occasions. From the user's home directory do a "ls -la" and check the owner and group of these two directories: .config .dbus If the owner and group are "root" "root" this could be the problem. To fix just do a "chown -R username.users .config .dbus". Of course, use the real username.
No too bad but thanks for trying, those two folders and all the subfolders and files in them are properly assigned to testusername:users here. Thats all right. What I observed in addition was a 100% cpu consuming task called kwin_x11 that had been eating/runnin at over 3000 time units,
Just grasping here, but ... when I find kwin_x11 using a lot of cpu, usually on nvidia based systems, a drop to runlevel 3 (multi-user) and reinstall of video driver. When returning to graphical, usage returns to normal. And kwin_x11 may be consuming enough of your cpu that the login is never reached. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/01/2020 17.23, cagsm wrote: | On Wed, Jan 29, 2020 at 5:07 PM Lew Wolfgang | <wolfgang@sweet-haven.com> wrote: |> This is a long shot, but I've had it happen to me on multiple |> occasions. From the user's home directory do a "ls -la" and check |> the owner and group of these two directories: .config .dbus If |> the owner and group are "root" "root" this could be the problem. |> To fix just do a "chown -R username.users .config .dbus". Of |> course, use the real username. | | No too bad but thanks for trying, those two folders and all the | subfolders and files in them are properly assigned to | testusername:users here. Thats all right. What I observed in | addition was a 100% cpu consuming task called kwin_x11 that had | been eating/runnin at over 3000 time units, dont know what top | column had shown as time units, well whatever this machine has | 41days uptime, and its maybe with 4 cpu cores could end up at | around those 40days or something of cpu sonumption of that | process. But I killed it forefully, now everything is basically | idle again but this didnt help either to login the test user. | | Is there some logging facility of the logon or plasma loading | process, where I could read something? Not that I'm aware. | Is it possible that maybe the desktop before showing is waiting for | some external devices, mount points or something? usb keys, usb | disks or such stuff? Can be, yes. Or NFS mount. I have read of it happening. | I have some useful data in the users home directory and I dont | really have the time right now to clean up or decide which files | and structures I could need and could be moved and which can be | deleted to be able to recreate the complete users home dir? or the | user as whole? Very probably the issue is some broken file. Check also /tmp directory | | this is some very basic setup, the userid is 1000 and basically | the first user that has been added to this machine like long time | ago. Dont know why this needed to be messed up this badly. | Basically I only do zypper up or autoupdate, and never mess with | packages or anything. Its a real pitty that opensuse in this terms | behaves much worse than any windows platform I ever came across to. | Meaning destroying very basic functionality and all defaults | vanilla vendor set stuff :( I would create new user, then exchange the directories (and change ownership). Then move to user 1000 the data directories, such as Documents. And those configurations of individual programs you need, copy them over. | | I am only an end user mostly. And I very much stay away from | deliberately mess with configs packages files or such stuff. | Especially the desktop things. Maybe this is also a reason why | linux desktop hasnt took off so far? ;) Seriously, this is really | immensely annoying. Well, it does happen with Plasma. You are not the first one. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXjHFJAAKCRC1MxgcbY1H 1c2qAJ0Rq9Z3/Zfnvqr615mGT513ivMdxgCfXhAQAoYzhsYdJfzq9CgZ1oov3Ww= =eVG7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [01-29-20 12:49]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/01/2020 17.23, cagsm wrote: [...] | I am only an end user mostly. And I very much stay away from | deliberately mess with configs packages files or such stuff. | Especially the desktop things. Maybe this is also a reason why | linux desktop hasnt took off so far? ;) Seriously, this is really | immensely annoying.
Well, it does happen with Plasma. You are not the first one.
now THIS IS FUD. It can happen with any desktop environment and/or operating system. You are spreading mis-information assigning system problems and/or user errors to a desktop like it is the only and more likely than others to be a problem. If you have found that, it is your personal failings and not the system/desktop as many other use it with few problems. Please be more careful with assigning blame. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/01/2020 18.55, Patrick Shanahan wrote: | * Carlos E. R. <> [01-29-20 12:49]: |> |> On 29/01/2020 17.23, cagsm wrote: | [...] |> | I am only an end user mostly. And I very much stay away from | |> deliberately mess with configs packages files or such stuff. | |> Especially the desktop things. Maybe this is also a reason why | |> linux desktop hasnt took off so far? ;) Seriously, this is |> really | immensely annoying. |> |> Well, it does happen with Plasma. You are not the first one. | | now THIS IS FUD. It can happen with any desktop environment | and/or operating system. You are spreading mis-information | assigning system problems and/or user errors to a desktop like it | is the only and more likely than others to be a problem. If you | have found that, it is your personal failings and not the | system/desktop as many other use it with few problems. | | Please be more careful with assigning blame. I'm sorry that you think that way, but it is simply my recollection that I have seen over the years several people with the same problem, and I don't recall people having it with gnome or xfce. Maybe because there are fewer users, maybe because they are less prone to this particular problem I don't know. I do not have any evil intent on to Plasma. I can say as well, that I have read that current Plasma may be less memory hungry than XFCE, because they have made that effort. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXjHS/QAKCRC1MxgcbY1H 1XLYAJ9U3arSr8nB4cwQAh7X/GYwVYPNgACeIEZ51f8I6qKA13s4Mz1HtZnfros= =6t6L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 29/01/2020 à 17:07, Lew Wolfgang a écrit :
If the owner and group are "root" "root" this could be the problem.
it's better to sudo <username> from root, when moving files, to avoid this, but I have to say I don't always think to do it :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/29/2020 08:23 AM, jdd@dodin.org wrote:
Le 29/01/2020 à 17:07, Lew Wolfgang a écrit :
If the owner and group are "root" "root" this could be the problem.
it's better to sudo <username> from root, when moving files, to avoid this, but I have to say I don't always think to do it :-(
Yes, me too! But in this case I mostly see root.root on .dbus and .cache right after creating a new user with "useradd". It doesn't happen all the time and is not repeatable. IIRC I first noticed the behavior back in the Leap 42.x series. I haven't taken the time to really track it down. I'm probably doing something stupid... Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/01/2020 13.04, cagsm wrote: | Hi openSUSE list, | | I had a post with no replies on support suse list: | <https://lists.opensuse.org/opensuse-support/2020-01/msg00123.html> Sorry, | I missed it. | meanwhile I have discovered that this test machine has come rather | a longer way with upgrades from previous opensuse releases. | | Everything worked fine until a few weeks ago. With some zypper dup | update, a normally working plasma desktop user was unable to log | into plasma ever after. zypper dup? You can not update Leap with "zypper dup". It has to be "zypper patch" or "zypper up" depending on your circumstances. Never "zypper dup" except on a single occasion: when going from, for example, 15.0 to 15.1. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXjHAyAAKCRC1MxgcbY1H 1b76AKCX3qu3oiq0PvTcMJkiEP974yE3VwCfTtMvH7uEY44Cvwfaar164MA083Y= =F8k5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jan 29, 2020 at 6:29 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
zypper dup? You can not update Leap with "zypper dup". It has to be "zypper patch" or "zypper up" depending on your circumstances.
Never "zypper dup" except on a single occasion: when going from, for example, 15.0 to 15.1.
yes mybad typo, zypper up obviously. but the system has been subject to some zypper dup as well in the past. thanks for pointing this out. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/29/2020 06:04 AM, cagsm wrote:
Hi openSUSE list,
I had a post with no replies on support suse list: <https://lists.opensuse.org/opensuse-support/2020-01/msg00123.html>
meanwhile I have discovered that this test machine has come rather a longer way with upgrades from previous opensuse releases.
Everything worked fine until a few weeks ago. With some zypper dup update, a normally working plasma desktop user was unable to log into plasma ever after.
Some extra local linux user accounts, whom had never used the gui login before and thus not created any plasma related config files and never logged into plasma, tried yesterday, still work fine and happily log into plasma. plasma for these users looks rather new and the menu looks more stylish than I remember it from that other user that is currently blocked from logging into plasma. Maybe as that older user has used plasma for a long period of time.
Anyhow, how would I make that one blocked user be able to login into plasma again? what config files can I look at, edit or whatever I need to do? I dont have actual real personalisation or specials for that user, only some xterm or konsole was running and always been restoring upon logon to that plasma desktop, thats basically all.
IceWM and KWM or those simplistic desktops do work for that plasma affected user as well. Help? TY.
Old stand-by fix: kbuildsycoca5 --noincremental You may have to try in the user's session -- if you can get it started to the point a session is running, otherwise, login as user and attempt to run from console. (I don't know if the plasma version will provide a session for it to run in -- never tried in plasma -- but kde3 is still working perfectly :) Good luck. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
cagsm -
Carlos E. R. -
David C. Rankin -
Istvan Gabor -
James Knott -
jdd＠dodin.org -
Knurpht-openSUSE -
Lew Wolfgang -
Patrick Shanahan