IIRC I caused something like this years ago, when experimenting with input methods. Again IIRC I enabled SCIM input, then could get through kdesu anymore. Anything in that region that you may have done?
You could try to get some output from a terminal. What happens if you “su”? What happens if you run “kdesu yast2” ?
I am too unexperienced with Linux to “experiment” with program and system settings. The only thing that would have changed with time would be the updates through Yast.
As a said, I can open a terminal, “su” and get root privileges using my root password; then Yast opens fine if I type and execute the yast2 command.
Conversely, when using my standard user privileges, the kdesu /sbin/yast2 command in a terminal opens a window (the same as the one open by the application launcher) which refuses my root password.
Note that this not the case, if I am logged as the new user that DenverD suggested to create.
It’s sure now that this is in your user account, since the new user does not have the problem.
Please do:
kwrite ~/.kde4/share/config/kxkbrc
, copy and paste contents here
pomchip wrote:
> There must be something wrong with my original profile.
yes, and with a LOT of patience and a tool like diff you might find
the find file(s) in your original /home that need repair…
i think i would begin with these files:
…Xauthority
…ICEauthority
…bashrc
bash.bashrc.local
then look in these directories
…config
…kde*
i would edit, click on, or otherwise touch any of those as root in a
GUI tool (like say a root powered ‘file manager’)…
do it as a simple user when in the GUI (sometimes, somehow * file permissions can be subtly changed by root
powered GUI tools and despite claims otherwise by some neophytes and
Window’s experts, such can lead to irritating unexplainable problems
file permission problems which can lock you out of your own home or
login, or [maybe, i do not know] keep you from opening the GUI YaST
even with the correct root password!!)…
or do the diff investigation in a real console as root…
if you can’t find the problem, you can always move your data (not
configuration stuff) over to the new user which works…or, just not
try to launch YaST from the old user (log out, then into the working
user and . . .)
by the way, make sure have a good strong password for any user you
named (say) Test or TEST or test or Guest or … or any other the
others the script kiddies might accidentally find…
happy hunting.
–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]
*
> more ~/.kde4/share/config/kxkbrc
[Layout]
DisplayNames=us,fr
IndicatorOnly=false
LayoutList=us,fr
Model=pc104
Options=
ResetOldOptions=true
ShowFlag=true
ShowSingle=false
SwitchMode=Global
Use=false
This is true, but actually only happens when root will for example move files or edit them, not by merely browsing within a users /home. File permissions do not get subtly changed (at least that would be a serious security bug, which is pretty unlikely to stay as a per se default). root is able to open files or view a users folder, but one should avoid changing anything within /home as root (not only with GUI tools, but also via command line).
pomchip, is there any difference in the file ~/.kde4/share/config/kdesurc between your two users?*
I just diff’ed the two files as root and got no differences.
gropiuskalle wrote:
> File permissions do not get subtly changed
define subtly.
–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]
Initially OK. I.e. nothing wrong with this one.
Actually I don’t have to define it (you brought up this term anyway, remember?). Permissions get changed via a definite action, everything else would be an unintentional bug.
I just mentioned it because in my opinion the implication of this causing the troubles discussed here is offtopic. Yet I would be interested if the behaviour you describe is documented anywhere; beside that → EOD.
+1 for you DenverD. There was a line (without any relation to yast) in my .bashrc file that was returning a error message to the shell from time to time (surprisingly, not when I tried kdesu /sbin/yast2). After commenting out this line, everything is back to normal.
Lesson learned: don’t mess with .bashrc or make sure there is no bug!
Thanks for your help guys.
pomchip wrote:
> +1 for you DenverD.
just a wild guess…you are very welcome…am happy you found and
repaired the problem…
–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]
Good guess. Well done.
There was a line (without any relation to yast) in my .bashrc file that was returning a error message to the shell from time to time (surprisingly, not when I tried kdesu /sbin/yast2).
Just out of curiosity: what line was that? I recently had a puzzling experience caused by the bashrc as well, that’s why I am interested.
I recently discovered that changing default root login shell to /bin/tcsh causes the symptoms described above. Yast from KDE will not accept valid root password. Further, when launching yast2 from command line, I get the configuration panel, but certain configuration items fail to launch (example “printers”).
To be precise, I should say that I took two steps at one time to correct this problem. (1) reset root passwd from command line to something simple like “abc”, and (2) change default root login shell from /bin/tcsh to /bin/bash. Following these two steps I then launch Yast from KDE. It now works. Then, step (3) change root passwd back to something more sensible. Following step (3) my KDE Yast is now working again.
So strictly speaking, I cant say I did the experiment to prove it was the /bin/tcsh. But I’d probably bet my paycheck that was it.
ej2pi wrote:
> I cant say I did the experiment to prove it was
> the /bin/tcsh. But I’d probably bet my paycheck that was it.
that sounds like a bug report waiting to be made, see:
http://en.opensuse.org/Submitting_Bug_Reports
and, your’s is another good reason to not bash bash!! 
–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]
Reposted from YAST does not accept root password
After further experimentation, I found my problem is not due to default /bin/tcsh login shell, per se, but rather an issue in the associated .cshrc file. From .cshrc I source another file, called .alias. If I give that filename as a relative path, like this:
source .alias
then Yast (when launched from KDE) will not accept my root password. If I give a full path, like this:
source /root/.alias
or
source ~/.alias
then everything works fine. Now I cannot say that this behavior changed from 11.0 to 11.3, because the full path is specified on my machine running 11.0. I suppose I could try the relative path over there to see what happens. But I do know that the KDE Yast launcher was NOT sensitive to this prior to my online updates (from fresh 11.3 install). There is no way I’ll ever know which update caused the change, because there were hundreds of updates between 11.3 iso release and 10/24/1020.
A bug? probably not. And I don’t know where stderr goes when you launch one of these KDE lauchers, so it is difficult for me to find out the detailed error. It likely cant find the .alias file in the pwd whatever that is when Yast is launched from KDE. This type of thing could bite somebody running tcsh, bash, or any shell, if something goes wrong in the associated shell startup script.
I’m reposting this to the earlier thread as well, for informational purpose. That user had similar issue caused by a .bashrc error