Bug 728554

*** Bug 728570 has been marked as a duplicate of this bug. ***

Seems not to be a "false" password.
Typing the first char into the password field returns one dot.
Typing the next char gives nothing.
Waiting aprox. 1 second and then deleting the first char with <backspace> clears the field.
After that input is recognized normally.

?

@Hendrik: same in your environment?

confirmed. But to be more precise, here with me, only the first non-root login attempt at KDM after boot fails. So the sequence "root, user1" does work (for both users), yet "user1, user1" fails for the first try of "user1", the second try succeeds. I did not find anything suspicious in the logs (respectively I did not find any message about an failed login attempt at all), the only difference between root and user1 is that the home directory for user1 is stored on another partition.

System was installed as RC1; updated via zypper to RC2. Setting priority to 3, since this is somehow irritating (and maybe authentication in general is affected).

My "confirmed" of #3 refers to the original bug description, not #2.

#2: no, input of the password is normal. Every keystroke echoes as a dot.

I have no problems typing the password. But strange enough: When I delete at least one sign with <backspace> during typing the password, even the first login after boot works.

I even don't have to type in anything at first. Just hitting backspace once (in the empty password box) and typing in the password afterwards results in a successful login (of a non-root user) at the first try.

BTW, mine is a x86-64 system.

*** Bug 731087 has been marked as a duplicate of this bug. ***

I am also seeing this problem.

It does not always occur for me.  It only happens for me when I login soon after bootup.  If I wait a few minutes, and then login, there's no problem.

It is looking as if the second character of the typed in password is lost.  If I watch closely, I see a response to the first char and then nothing for the second char.  If I repeat the second char, then continue with the rest of the password, login is fine.

While I suspect this is a "kdm" problem, I am not certain.  It does not happen with "gdm".  However, a "gdm" login requires addition mouse clicks or ENTER key before entering the password.  Additional mouse clicks would probably also prevent the problem from happening with "kdm".

Good morning i`m using openSUSE Tumbleweed with 12.1 as base.
It seems that the problem at the login prompt is affecting only KDE 4.7.2; pressing backspace key and typing my password after did helped
Here is some output from /var/log/message when the login error happens:

Registered Authentication Agent for
unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.32
[/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path
/org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)

I also have Gnome 3.2 and the login process goes without any problems.

(In reply to comment #9)
...

Forgot to say that i have a 64 bit operating system. So i guess that both 32 and 64 bits systems running KDE 4.7.2 are affected.

Same problem. When I log in as root first - the problem happens then my regular login as myself as a user has no problem. Where as above I log in as myself first the problem occurs and the root login has no problem. Thus the second user no matter who it is has no problem. As reported on the network forum I also have a problem with the second log in after the install [ this has happend twice ] the network connection is lost. The third login and after the network cannot even be restarted. I don't know if there is any connection, but I have not experienced either of these problems before. I have just also set up a http service on the machine. My system is also 64 bit. I will check out my Gnome login now.

Updated to KDE 4.7.3 this evening and the first login still fails eve using this upstream version.

It should be the same bug.
On my dell latitude e6510 laptop with fresh suse 12.1 and kde 4.7.2
At login I usually use non automatic login, in 11.4 the focus was on the password field and I typed the password and everything went well, now in 12.2, the same steps brings to me to insert a wrong password, is not my failure, the first times I thougt it was me, then I tested for few days, the first password I insert is wrong, and it is due to typing speed, the second is ALWAYS correct with the same typing speed or faster, to have a correct password insertion at the first attempt I have to type very slowly a stroke each 2 seconds.

Did anyone noticed that the login issue is no more ?
I don`t seem to get it anymore even when i type my password fast and without pressing backspace. Can anyone confirm this ?

Still here with KDE login.  I believe it never existed with Gnome.

On my old slow single core cpu laptop it still happens every time.
On my desktop machine with a more powerful dual core cpu it happens very rarely.

@Roland Hughes: i have both KDE 4.7.2 from stable version repo`s not upstream plus Gnome 3.2 and i`m not experiencing the problems. What KDE do you have ? 

@Hendrik Woltersdorf: thats weird :)

If this issue still happens with the final release of openSUSE 12.1 please ensure to update the 'Version' field accordingly.

The version is now "Final".

The same issue got reported on the general openSUSE list.  See http://lists.opensuse.org/opensuse/2011-12/msg00200.html

@Lars: Did you change the version from "final" to "RC2" on purpose?

>@Lars: Did you change the version from "final" to "RC2" on purpose?

I assume that was an accident.  He was probably creating a comment, and had started it when the version said RC2.  So that was the setting on his screen for the submission.

Yes, I agree this is still a problem for final, and I'll try adjusting the version back to final.

(In reply to comment #17)
> @Roland Hughes: i have both KDE 4.7.2 from stable version repo`s not upstream
> plus Gnome 3.2 and i`m not experiencing the problems. What KDE do you have ? 
> 
> @Hendrik Woltersdorf: thats weird :)

Whatever came on the FINAL DVD.

(In reply to comment #22)
> >@Lars: Did you change the version from "final" to "RC2" on purpose?
> 
> I assume that was an accident.  He was probably creating a comment, and had
> started it when the version said RC2.  So that was the setting on his screen
> for the submission.

You hit the nail by the head.  Sorry.  As I've used bugzilla two or three times before I should have been aware of this.

ok, back to the beginning.
it is _not_ typing <backspace> after the first char.
it's waiting for ending hard disk activity after the first keystroke, right?
assigning to a real person
Will?

No, I think it is not waiting for hard disk activity. Waiting some minutes does not help. But typing <backspace> somewhere during entering the password does always help.

I don't know why this is going on so long.  It is a classic case of an uninitialized field.  Either the object is improperly created, or the length isn't correctly set.  If someone sends me a link to the KDM source file, I will take a look for the obvious.  No, I don't want a link to the trunk and the build/svn instructions, just want the one or two source files for the login dialog.

On my suse 12.1 case waiting some second from a stroke and another result in a correct password

Same issue here on my main work desktop. Never happened to me in the past with any previous versions of openSUSE.  I found the workaround is to hit backspace several times in the password field, and then to type the password for real. Almost seems the password field in KDM is prefilled with invisible garbage.

*** Bug 738106 has been marked as a duplicate of this bug. ***

Good day, i have openSUSE 12.1 inside VBox only with openSUSE official repo`s and the issue is still present. On my real machine i have openSUSE 12.1 with additional KDE repo`s from Distro Stable found here http://en.opensuse.org/KDE_repositories#Stable_aka._KDS_.28KDE_SC_4.7.29 and i have no fail at first login attempt. Can anyone with this additional repo`s confirm this ? :)

I added the repos "Core packages" and "UpdatedApps" from your link, zypper dup-ed, rebooted - and the bug is still there :(

Damn... my apologies for that Hendrik, i put the wrong link in that post. The link with repo`s used by me is this one: http://en.opensuse.org/KDE_repositories#Updated_applications_only 

"Updated applications only
If you're using the official, supported and tested core KDE packages provided with the distribution, there are these additional repositories available for your consideration. " 

And i have all of them enabled. Extra, Updated Apps and Playground. Once again sorry for my type error in my previous post :(...

OK, I reinstalled the operating system, activated now these 3 repos, zypper dup-ed, rebooted - and the bug is still there :(

I have openSUSE 12.1, using the 32 bit architecture. Keyboard is connected to the PC via a PS2 port. How about you ? Could this be a keyboard (hardware) issue  as well ?

(In reply to comment #35)
> I have openSUSE 12.1, using the 32 bit architecture. Keyboard is connected to
> the PC via a PS2 port. How about you ? Could this be a keyboard (hardware)
> issue  as well ?

The short answer would be no.  As an author I swap out my keyboard every couple of weeks to break up the monotony of typing.  I have a stack of about 8 or so keyboards, all different makes and models, PS/2 and USB.  Problem happens with all of them.

That said.  I'm 64-bit AMD and you are 32-bit.

Thanks for the answer Roland so i guess a hardware issue is out of the question and thus the bug is still "kde territory" :)

Same issue, but (for me at least) it's clearly a timing thing. When I start typing the password on first login, the first char is accepted (dot appears) and then several more are not (no dots). Then of course the login fails. If I wait a few seconds after typing the first char of the password, I have no such problems.

SuSE 12.1 x86_84 clean install, standard KDE environment. /home is on a separate LUKS partition, in case that matters. Waiting after boot-up before starting to type anything does not help. I do see the message from Comment #9 but it comes right after booting, not when I try to login, so I don't think it's that. It has to be something that gets triggered with the first character I type, and then takes some time before more input is accepted.

(In reply to comment #38)
> Same issue, but (for me at least) it's clearly a timing thing. When I start
> typing the password on first login, the first char is accepted (dot appears)
> and then several more are not (no dots). Then of course the login fails. If I
> wait a few seconds after typing the first char of the password, I have no such
> problems.
> 
> SuSE 12.1 x86_84 clean install, standard KDE environment. /home is on a
> separate LUKS partition, in case that matters. Waiting after boot-up before
> starting to type anything does not help. I do see the message from Comment #9
> but it comes right after booting, not when I try to login, so I don't think
> it's that. It has to be something that gets triggered with the first character
> I type, and then takes some time before more input is accepted.

Your description makes it sound like someone has a focusInEvent() handler which goes out and verifies the network connection after the first keystroke.

http://developer.qt.nokia.com/doc/qt-4.8/qlineedit.html

If they aren't using Qt, something equivalent happening when field gains focus by first character entered.  Network verification would make sense.  ALTHOUGH, When a person starts Libre Office to edit an existing document, a very similar thing happens.  The document is displayed, but it is several seconds before you can type anything without the characters being eaten.

This might be related to the file selection box lag problem if what is really happening after the first character gets entered is the opening of the UAF so the password and user can be more quickly verified.  Sorry, don't know Linux name for User Authorization File.


For those who are into doing clean installs...do one more.  This time make both your root and home partitions EXT3 instead of the default EXT4.  See if the problem persists.

I did my today's reinstall on ext3. That didn't change anything. In the past I tested btrfs too without success.

(In reply to comment #40)
> I did my today's reinstall on ext3. That didn't change anything. In the past I
> tested btrfs too without success.

Thanks.

One has to look at the code now.  I don't know what it was written in or where it is, but, there has to be some kind of "onFocus" or "onEntry" or "textChanged" etc. type even which is issuing an interrupt blocking call.  Most likely something to do with verifying a network connection, but, it could simply be attempting to open the file with user and password information.  Whatever that particular routine is doing, it needs to be moved to the actual logon attempt.  They must have tried to save time, and until this severely slow IO bug got introduced to Linux (nearly everything attempting to open a standard file dialog gets bitten by it) there wasn't a problem.  Now it is and I don't expect the IO issue to go away, only get worse as more types of IO are added to the system.

Created attachment 470293 [details]
dependency tree of kdm

my observation of this bug is a little different:

- first character is accepted
- then input field locks up, cursor stops blinking.
- if you wait for cursor to return, you can then fill in the rest of your password, after which you can login.


I think it is somewhere in kdm-4.7.2-6.4.1.x86_64, specifically the login part of it. The locking up of the input field happens for a reason, it cannot happen magically.

rg

My observation is - this bug appeared only on OpenSuse 12.1. When I had OpenSuse 11.4 and KDE 4.7.2, 4.7.3 and 4.7.4 (installed from http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_11.4/) login worked OK.

On OpenSuse 12.1 this bug is present both for KDE 4.7.2 and for 4.7.4.

Like I said before.  This bug is related to one of the many "slowness" and "hanging" problems associated with 12.1.  I don't have the source code to look at, but after you type the first character in the field there is some kind of on_active or on_entry even which gets triggered with the first character.  This event is either attempting something with the network or something with the disk (like opening the file so it can verify password later) and that hang is blocking keyboard IO because it blocks all other interrupts until complete.

roland, 
I think that your observation is incorrect. 

on entry code starts before you can input anything. ( mouse click, keyboard, whatever )


this one allows one single input token (click or character, and then starts a lot 
of disk IO, and then continues.

apparently something gets loaded (some library or whatever )

the source code is not so difficult to find.

should be KDM or underlying code, consolekit or so..

I noticed this is not only the inputfield for the password.

it also happens when you click the menu item, if you want to select a different
windowmanager.


the whole thing freezes after the first event (keyboard or mouse) for a few seconds. (lots of disk I/O)


rens

(In reply to comment #46)
> roland, 
> I think that your observation is incorrect. 
> 
> on entry code starts before you can input anything. ( mouse click, keyboard,
> whatever )
> 
> 
> this one allows one single input token (click or character, and then starts a
> lot 
> of disk IO, and then continues.
> 
> apparently something gets loaded (some library or whatever )
> 
> the source code is not so difficult to find.
> 
> should be KDM or underlying code, consolekit or so..

I only use professional source code management systems.  These do not allow subdirectories or any of the other God-awful traits of CVS and SVN.  If someone posts the actual source I will look at it, but under no circumstances will I enter into the abyss the KDE project calls source code control.

My observation is correct, we simply have different symantecs/verbage.

Both yourself and the other poster seem to agree it is disk IO, not network.  Thus we have identified the problem.  There are many other bugs reported with this release about "hanging" disk IO, massive slowness, and file dialogs which take forever to load.

I believe this is a problem due to EXT4 support.  Another tried using only EXT3 and claimed to have the same problem.  That doesn't really rule out the code added to support EXT4.  EXT4 has taken a loooooong and bug ridden time to roll out.  Even the backup utility I use cannot yet allow me to restore a single file from an EXT4 partition as it can with any other format.

This problem is with the disk IO.  Were someone to remove the disk IO from the "on-entry" code (for lack of better verbage) and move it all to the post-entry validation section, we SHOULD see the hang/hesitation/lock-up move to there.

I tested this issue with different DISPLAY_MANAGER settings:

kdm and lxdm. 

both allow you a choice of desktop to boot.

the issue does NOT occur with lxdm, only with kdm.

so there is good news:

- the workaround is to 
    install lxdm base package, which contains the lxdm display manager.
    replace kdm with lxdm and boot KDE4 with it. ( /etc/sysconfig/displaymanager,
 )

- it has nothing to do with ext4 or btrfs, because the issue goes away with changing from kdm to lxdm

If that is practical, I have bootchart graph and files, 
which show activity between start of KDM and ksplash

perhaps that contains something usefull.

just drop me a mail.

rens

It is still something disk or network related.  Something KDM is doing that lxdm isn't.  If you could chart BOTH kdm and lxdm I think we would be able to identify it.

This past week I've been using one of my USB keyboards and booting quite a bit due to some network issues.  If I start typing my password the INSTANT the entry field becomes visible I don't have the problem  MOST of the time.  If I'm even one second late, my password isn't recognized because the second and third character are eaten by whatever is going on.

Created attachment 472198 [details]
strace output from first and second login

I strace'd kdm during a first and second login. I can see a lot of files (config, icons, theme ...) getting opened in the first trace log. But I am not able to detect my first key stroke in the log. Maybe someone else can read something out of these logs.
I used for this test username "hendrik" and password "geheimwort1". You will find those strings in the logs; but in the first one without the second and third character.

Another test: I activated in /usr/share/kde4/config/kdm/kdmrc in section "[General]" the setting "AutoRescan=false".
Since then the problem is gone.
Can anyone confirm this?

disclaimer: I do NOT recommend to use this setting except for testing until someone with more inside knowledge than me, tells us if it is safe. Otherwise it might be necessary to reboot the machine to get changed settings to work...

(In reply to comment #53)
> Another test: I activated in /usr/share/kde4/config/kdm/kdmrc in section
> "[General]" the setting "AutoRescan=false".
> Since then the problem is gone.
> Can anyone confirm this?
> 
> disclaimer: I do NOT recommend to use this setting except for testing until
> someone with more inside knowledge than me, tells us if it is safe. Otherwise
> it might be necessary to reboot the machine to get changed settings to work...

Thanks for definitively proving this problem is directly related to the current slow-hanging-disk-io problem KDE and Linux in general has been experiencing since EXT4 started making its appearance.

According to the doc.

http://docs.kde.org/stable/en/kdebase-workspace/kdm/kdm-files.html

========
AutoRescan

    This boolean controls whether kdm automatically re-reads its configuration files if it finds them to have changed.

    The default is “true”.
=========

This explains the sheer randomness of the issue since it depends both upon the amount of disk IO currently going on AND if the network has a blocking interrupt causing disk IO to wait.

I propose we push this bug to the people working on the slow-hanging-disk-io issue.

Possibly this bug.

 734518

Definitely one of the IO bugs is at the root of this.

(In reply to comment #53)
> Another test: I activated in /usr/share/kde4/config/kdm/kdmrc in section
> "[General]" the setting "AutoRescan=false".
> Since then the problem is gone.
> Can anyone confirm this?
No change.
> 
> disclaimer: I do NOT recommend to use this setting except for testing until
> someone with more inside knowledge than me, tells us if it is safe. Otherwise
> it might be necessary to reboot the machine to get changed settings to work...
The issue is about the first login after boot. So how to test this changed setting without reboot?

(In reply to comment #55)
#734518 is about snapper/zypp/btrfs
I don't use btrfs, but tried removing snapper because Roland might be right with
<sarcasm>
the "root of this" is "Definitely one of the IO bugs"
</sarcasm>
No change.

This is not a bugzilla, maybe a forum or mailing list thread.
A bug should be mentioned by developers, shouldn't it?
So I assigned this to Will, who didn't answer yet. Why? I don't know and I'm not happy with that.
But you:
you all also don't know but you all keep acting like probing "this" and accusing "that" might be the cause and maybe the solution of the problem.

But back to the facts:
it's a KDE/KDM thing, so telling other people: use another login-manager and then continue to use KDE does nothing good.
stracing kdm (as i did in the first place) leads to nothing because you can't trace with this utility what happens fulfilling the password-editbox.
There _is_ a blocking delay after the first keystroke inside the password field.
And this blocking delay has a relation to harddisk activity right after this very first keystroke.

So as this is a bugzilla: let's wait and hope a real developer would explain/resolve this.

There's a bit too much discussion (and blind guessing) here.

On my slowest machine (a 32 bit system), I clearly see the cursor stop blinking after the first char.  Then it won't accept another keystroke until it starts blinking again.  This is as reported by rens groenewegen in #43.

On that same machine, I last rebooted on Friday.  I had the problem on the first login after boot.  Then I logged out.  The system sat relatively idle (but no suspend to memory) from Friday afternoon until this morning, though I did login remotely via ssh over the weekend.  Then I saw the same problem on the first login this morning.  So this is not just a "first login after boot" problem, though that is when it is most obvious.

I am using ext4, so btrfs problems are not the cause.

(In reply to comment #57)
> There's a bit too much discussion (and blind guessing) here.
> 
> On my slowest machine (a 32 bit system), I clearly see the cursor stop blinking
> after the first char.  Then it won't accept another keystroke until it starts
> blinking again.  This is as reported by rens groenewegen in #43.
> 
> On that same machine, I last rebooted on Friday.  I had the problem on the
> first login after boot.  Then I logged out.  The system sat relatively idle
> (but no suspend to memory) from Friday afternoon until this morning, though I
> did login remotely via ssh over the weekend.  Then I saw the same problem on
> the first login this morning.  So this is not just a "first login after boot"
> problem, though that is when it is most obvious.
> 
> I am using ext4, so btrfs problems are not the cause.

And a big part of the blind guessing is caused by the ASS-U-ME ption that when it happens it is always the second character.  This is patently false.  On the machine I got rid of yesterday I could log in many times just fine, sometimes second and third character eaten, sometimes a pair out of the middle, other times it was characters at or near the end.  

On the machine I've been building over the course of the last two days (couldn't start until after 3PM when UPS arrived with the last of the parts) the problem has NEVER happened.  I've booted more than a dozen times without seeing the effects.  Granted, I'm on a 3Ghz quad core now instead of a dual core from 2007, but, I should have seen the problem.

The only thing significantly different configuration wise is that I followed this advice to the letter when disabling animation.

http://mschlander.wordpress.com/2011/01/23/kde-is-slow-for-dummies/

Before I had just disabled enough to get the most annoying things out of the way.

I have a few more things to test and install since I still have a PP card coming, but, you all might want to try disabling animation as instructed via the link, especially on the very slow machines.

FYI: I don't see this bug when using using the kdm-branding-upstream package (and kdm-4.8). As soon as I switch to kdm-branding-openSUSE it appears again.

Good day, this problems still happens under openSUSE 12.2 Milestone 1, KDE 4.8.

Hans,

correction: by not using kdm i get rid of the problem,
 so something does happen: I am not being annoyed by this bug.
however, I need separate login sessions, so that does not work for me :-)

some input here:

it is not (as you state below) only keystroke.

click with the mouse on the menu items low lefthand corner, to (example) select a different windowmanager and exactly the same will happen: freezes for 5-7 seconds, no input is taken (including mouseclicks), meaning that all desktop IO is frozen.

perhaps systemd (which is responsible for starting stuff like logind and consolekit and so on....) is too slow or should preload whatever is needed here.



(In reply to comment #56)
> (In reply to comment #53)

> There _is_ a blocking delay after the first keystroke inside the password
> field.
> And this blocking delay has a relation to harddisk activity right after this
> very first keystroke.
>

(In reply to comment #61)
> perhaps systemd

Don't blame systemd for everything, please ;-)
I also see the freeze after typing the first character of the password booting with sysvinit. And I still see this bug with KDE 4.8.1 on 12.1 (tested with sysvinit and systemd, no difference).

hmm, sorry.
just had a fight with systemd, so was a little biased :-)

yep, you are right. it's something kde related. cuz with lxdm the issue is gone....

<sigh.>
No response from the kdm maintainer.
Wild guessing keeps going on.
</sigh.>

KDE maintainers, can we please get instructions how to debug this further?

Unfortunately I did not found the file to turn kdm into debug mode.

(In reply to comment #43)
> my observation of this bug is a little different:
> 
> - first character is accepted
> - then input field locks up, cursor stops blinking.
> - if you wait for cursor to return, you can then fill in the rest of your
> password, after which you can login.
> 
> 
> I think it is somewhere in kdm-4.7.2-6.4.1.x86_64, specifically the login part
> of it. The locking up of the input field happens for a reason, it cannot happen
> magically.
> 
> rg

I can confirm your observation exactly
and I'm thinking too there is something wrong in kdm.

So I made the following test.

I replaced the kdm-branding-openSUSE packet
with kdm-branding-upstream packet.

After that the problem is present not any more.

(In reply to comment #66)

I did the kdm-branding swap to see if I can confirm that.
I can't. the problem is still there.....

so in my case this was not a solution. the only effective workaround is not using kdm to start kde...........




> (In reply to comment #43)
> > my observation of this bug is a little different:
> > 
> > - first character is accepted
> > - then input field locks up, cursor stops blinking.
> > - if you wait for cursor to return, you can then fill in the rest of your
> > password, after which you can login.
> > 
> > 
> > I think it is somewhere in kdm-4.7.2-6.4.1.x86_64, specifically the login part
> > of it. The locking up of the input field happens for a reason, it cannot happen
> > magically.
> > 
> > rg
> 
> I can confirm your observation exactly
> and I'm thinking too there is something wrong in kdm.
> 
> So I made the following test.
> 
> I replaced the kdm-branding-openSUSE packet
> with kdm-branding-upstream packet.
> 
> After that the problem is present not any more.

Created attachment 481705 [details]
chart of processes during +25 seconds, just before and after login

Created attachment 481706 [details]
bootchart of the same +25 seconds of processes so graph can be reconstructed

*** Bug 752710 has been marked as a duplicate of this bug. ***

Hi,

I just tried the kdm-branding-upstream (4.7.4-6.31.2) this one worked for me.
But it gave me this blue striped login screen - which i don't like much ;-)

So I switched back to kdm-branding-opensuse (12.15.4.24), and tried another workaround.

I changed the line

FocusPasswd=true to FocusPasswd=false

in usr/share/kde4/config/kdm/kdmrc in section [X-:*-Greeter]

Reboot.

From now on the Username is focused in the login screen, just press enter and type the password. For me it worked.

BUT - nevertheless the bug is still there and need to be fixed.

Hope this could help some of you...

Cheers
Dirk

I have this on opensuse 12.1 64bit kde 4.8.1

(In reply to comment #71)
> Hi,
> 
> I just tried the kdm-branding-upstream (4.7.4-6.31.2) this one worked for me.
> But it gave me this blue striped login screen - which i don't like much ;-)
> 
> So I switched back to kdm-branding-opensuse (12.15.4.24), and tried another
> workaround.
> 
> I changed the line
> 
> FocusPasswd=true to FocusPasswd=false
> 
> in usr/share/kde4/config/kdm/kdmrc in section [X-:*-Greeter]
> 
> Reboot.
> 


This did NOT work for me.  OpenSuSE 12.1  AMD Quad Core 64-bit.

I notice that the second keystroke never gets detected on the first try. It's only the second stroke, the rest will work. So if my password is 12345 and I type into kdm 12345, it will detect 1_345.
If I type 122345, it will fail to detect the second stroke and see 12345.

checked that, same here.

so there is blocking IO, some piece of code turns the (keybd/mouse) interrupts OFF
otherwise the character/click would still be queued.....

now, what is turning of the kbd/mouse interrupts ?

(In reply to comment #74)
> I notice that the second keystroke never gets detected on the first try. It's
> only the second stroke, the rest will work. So if my password is 12345 and I
> type into kdm 12345, it will detect 1_345.
> If I type 122345, it will fail to detect the second stroke and see 12345.

So, I upgraded to the 3.3 kernel using the mainline suse kernel repos:
http://download.opensuse.org/repositories/Kernel:/stable/standard/

The problem appears to be fixed. I will let you know if I have any issues.
Perhaps this was a driver problem or X issue?

Nevermind, still happening. Sorry for jumping the gun.

I see that I cannot type the second letter in my password until after the insertion point blinks. This is true 100% of the time.
So waiting until the insertion point blinks will let you continue typing your password like normal.

openSUSE 12.1, 32 bits; 2 days ago i have upgraded from kde 4.7.2 to kde 4.8.2. Untill now i did not experienced failed first logins at the login prompt. 

Can someone using kde 4.8.2 confirm this behavior ?

On my suse tumbleweed with KDE 4.8.2 the bug is still there.

(In reply to comment #79)
> openSUSE 12.1, 32 bits; 2 days ago i have upgraded from kde 4.7.2 to kde 4.8.2.
> Untill now i did not experienced failed first logins at the login prompt. 
> 
> Can someone using kde 4.8.2 confirm this behavior ?

OpenSuse 12.1 64 bit, KDE 4.8.2. Bug is still there.

*** Bug 740088 has been marked as a duplicate of this bug. ***

I was not able to reproduce this issue in openSUSE 12.2 Milestone 3. Is it only the first boot after install, or every time you boot the machine?

Also, this bug is set to NEEDINFO. What info is needed exactly?

@Malvern: On my machine (12.1, 64 bit, KDE 4.8.3) I'm never able to enter the second character of my password immediately - So the answer to your question is "every time"
As someone already stated above, if you accidentally mistype the password the first time, then on the second trial there is no delay anymore.
Is someone working on that bug?

FYI: I just tried to log out and in again (that is, without rebooting) - then there is no delay, as expected

*** Bug 766259 has been marked as a duplicate of this bug. ***

Good evening, i have seen this behavior on openSUSE 12.2 Beta 2, kde 4.8.4, second character of my password is not typed in the password box. Can anyone confirm this?

(In reply to comment #88)
> Good evening, i have seen this behavior on openSUSE 12.2 Beta 2, kde 4.8.4,
> second character of my password is not typed in the password box. Can anyone
> confirm this?

YES

(In reply to comment #89)
> (In reply to comment #88)
> > Good evening, i have seen this behavior on openSUSE 12.2 Beta 2, kde 4.8.4,
> > second character of my password is not typed in the password box. Can anyone
> > confirm this?
> 
> YES

This is the longest period of a bug being present since i have started to use Bugzilla :)

One more info:
I have one encrypted hard disk (containing just some data, nothing necessary for booting or logging in or so), and when I enter the encryption password during the booting procedure, than later on in kdm there's no delay! Actually I didn't expect that, so maybe this could be a hint for people with more knowledge than I have...

Still present in openSUSE 12.2 RC1 (Build 0050)

Confirmed. I repeat my earlier question, WHAT info is needed. We cannot ship with this bug! I suggest it be set to "blocker". Something as simple as logging in to your computer should *work*.

(In reply to comment #93)
> Confirmed. I repeat my earlier question, WHAT info is needed.

See comment #65

(In reply to comment #94)
> (In reply to comment #93)
> > Confirmed. I repeat my earlier question, WHAT info is needed.
> 
> See comment #65

I asked on #kde-devel on irc, and people gave me two hints:

In general, in order to find out what kdm is doing, one can use the kdm option "-debug <n>", with <n> being some number. Check out the kdm README file distributed with the source repo (get it via git clone git://anongit.kde.org/kde-workspace.git)

The second advice is probably not big news for people dealing with that task, but anyway, as it's a suse specific bug, it could/should have sth to do with the vkbd integration, as someone told me.

one more thing about my last comment (#91): i'd now say that there's *sometimes* no delay after entering that decryption password, not *always* - doesn't make it easier, i guess ;)

It seems the -debug option doesn't really help. No special messages in the log.

I did some debugging with strace and perf and I suspect that after the first key is pressed something is loaded or processed and this makes KDM hang for a short moment.

strace shows that /var/tmp/kdecache-root/icon-cache.kcache is processed which is 10MB big. I guess not KDM is loading it, but some other process because deleting the file and restarting KDM doesn't show the bug.

I will continue debugging it.

After some more observation I'd restate the error description as follows, hoping it could give somebody a bright idea where to look:

- The first dot appears promptly, and presumably the first character is always accepted as well.

- If I go on to type the whole password rapidly, the subsequent dots only show after some delay but the whole string is read and login succeeds.

- If I type more slowly, then it seems that the later keystrokes -- after that 1-2 second delay -- somehow cause the earlier ones to be discarded. Fewer dots appear, and login fails.

Maybe this helps?

ladies and gentlemen,

this is enough info provided.

I suggest we put this in the hands of the assignee now.

I do not think one could ship an OS with a bug like this.

RG

Is this still present? I had no trouble logging in in 12.2RC2. Can anybody else confirm?

(In reply to comment #99)
> Is this still present? I had no trouble logging in in 12.2RC2. Can anybody else
> confirm?

It still exist in RC2. I can confirm.

It is still there, in RC2, I confirm too.

It still exist in 12.2 rc2, hope it can be solved before release

I have this problem with 12.1 (i386, KDE 4.9 from KDE_Release_49 repository).

This bug should be a ship stopper for 12.2. There is no reason for user login to fail unexpectedly on any OS.

Just installed the brand new final 12.2 64bit

Too bad the bug still exist...

Updated to final *sigh*. It amazes me that the first thing a user encounters when using their computer with 12.2 is a bug.

I have this problem also by the openSuSE 12.2 Final. My Hardware ist a VMware Player 5.0.0 with a AMD-Processor.
By the openSuSE 12.1 the Login works by my without problems.

Opensuse 12.2 kde x64 in virtualbox.
Problem is still present...

Problem appears to occur whenever using the themed greeter, but not otherwise.  The greeter itself is missing the second character, and sending on the elided string to kdm, which sends it to PAM, where it (of course) fails.  Two difficult facts (at least locally): it does not occur after a kdm restart, but only after a reboot; further, it does not seem to be prevented by waiting for the boot to complete.  The latter would tend to rule out a lot of boot-time race conditions or incorrect init script dependencies, and the former just makes test cases really expensive.

This does not seem to occur in any distribution other than SuSE.  KDM now has at least 16 patches against vanilla source, some of which are very extensive, so it is somewhat difficult to see what may to be blame.  Further, the problem may not be in the kdm package itself.

I tried rebuilding without some of the more sinister looking patches, but the problem persisted.  Further experiments along this line are unlikely here, as kdebase4-workspace takes considerably longer to build on my machine than all of kde3 used to, and it simply isn't practical to try combinatorial patch-removal builds.

Since there was some question above as to how to debug this, here are some notes:
1. kdm config in SuSE is scattered across /etc/sysconfig/displaymanager, /usr/share/kde4/config/kdm/kdmrc, and /var/adm/kdm/.  I am not sure how this is merged, but kdm doesn't seem to like it, as it always complains about duplicated sections/keys (old, old SuSE bug).
2. One can add -debug $SOMENUMBER to the init script.  Choose your debug flags carefully, as some generate a lot of not-very-helpful output.  All of this goes to syslog by default, which is probably not what is wanted.
3. Rebuilding kdm is straightforward, if slow, but make sure to install all appropriate packages, not just kdm.
4. Running kdm through gdb is not at all straightforward due to the multiprocess program design.  Although since I am mostly sure the problem occurs directly in the greeter, perhaps it is not so bad.
5. There is nothing obvious in the .spec's changelog to identify this, assuming it first appeared around 11/11.

As this is now an almost 11-month old bug with no action from the KDE maintainers, I think it is safe to say that some suser will have to solve it.  I will see what I can do without rebuilding kdm anymore, but it would be interesting if someone could find a non-buggy kdm that works on 12.2 or some other information that might narrow the scope further than "probably in kgreet_classic.so", which is where I currently am.

I too can see this bug on my openSUSE 12.2 (had it on 12.1 too) x64 running on lenovo E420 laptop and can confirm above described behavior/conditions. Is suse only distro seeing this on same KDE version?

Definitely not present in Arch linux.

I can confirm this Bug on 12.2 but not on 12.1 and I can on 12.2 not logon to textconsole (Strg-Alt-Fx) see Bug 779443. Is it a install problem?

Vanilla build of kdm+greeter plugins still exhibits the same bug.

To the best of my knowledge, this bug is specific to SuSE.  At least Debian squeeze, sid, and Fedora 17 do not have it, and there seem to be no reports of it that google can find that involve another distribution.  It seems not everyone sees it on 12.1, or 12.2, either.

This bug is much older than it seems to be.

I first recognized it in openSUSE 11.4 64bit with KDE 4.7.2
And I still have a VirtualBox (openSUSE 11.4 32bit with KDE SC 4.7.4) where this bug is present.

Here is a report in the KDE bug forum complaining about it a few month before 12.1 was released:
https://bugs.kde.org/show_bug.cgi?id=280982

Using 11.4 I never complained about it, because I first thought its me or my keyboard, and shortly after that I upgraded to 12.1 as it was released.

With 12.1 on my desktop I first realized this is a bug and I could reproduce it always.
With 12.1 in a VirtualBox I recognized this bug only 2 to 4 times from 10 login's.

With 12.2 (which I have only on my desktop) the bug is still present.

Hope this bug will be fixed soon, I still rely on my work-around (comment #71), but this bug is really annoying.

I haven't made much progress, but I've learnt a few things that may be useful.  First, even when keypresses are dropped, XLookupKeySym() is still called for every press.  This would tend to indicate that it is not a problem with keymaps, evdev, the kernel, or X.  However, KDM still doesn't get the full string-sometimes it gets as little as one or two characters out of eight.  In fact, as is intuitive, I don't think the QLineEdit that runs the password field gets the full string either-so the keypresses are being read by Qt, looked up, but dropped somewhere (in the event loop?) before QLineEdit can update its state.  Unfortunately, I do not know enough about Qt to even guess where to begin debugging such a problem-just guessing at where to set a breakpoint seems impossible right now.

Discouragingly, the theme code is also pretty simple.  While it continues to be the case that the unthemed greeter works and the themed one does not, I cannot determine from inspection of the themed code where anything could be amiss-it would seem to have to be in widget construction perhaps in adding an event filter, but this does not seem to be the case.  Perhaps someone more knowledgeable about Qt can make a suggestion.

Henryk and others, I can't do much here except say thankyou for your hard work.

Created attachment 508743 [details]
list of installed rpm's suse 12.2


after zypper dup'ing from 11.4 to 12.1 to 12.2 
I now lost the bug.

perhaps the software list is helpful.

regards

rens

*** Bug 785018 has been marked as a duplicate of this bug. ***

Problem still present in 12.2.

I've the same problem only on my netbook. Laptop and PC hasn't this problem. 

openSUSE 12.2 i686; KDE 4.9.2 "release 511"; kdm 4.9.2-782.1;

I also experience this on all my 12.2 systems. It only happens the first time you log in and a lot of disk activity is just after the first character entered.

the way I circumvent this, is by actually inputting the first character of the password; wait shortly and then continue. Generally one second is enough I believe.

So it seems that the input is missed at the time the disk activity is taking place.

At first I thought that maybe systemd wanted to start something else needed but that was just a wild guess as I haven't closely checked the logs/activities.

ps, not only 64 bit, also 32 bit is affected.

I did an patch/fix update on this zypper dup'ed 12.2 install (mentioned below), and the bug is back.

noticeable difference:
Before the update, the KDM loginscreen looked like TWM: flat, no fancy graphics.
Apparently the normal login SuSE theme was missing or not digestable.

After that got fixed during the update, it has the openSuSE "branding"

I just upgraded my desktop from 11.4 straight into 12.2 (on a cloned partition, thank you very much)
difference: I had the 12.2 update added as repo, which I did not on the laptop upgrade. The bug is not there, everything fine.

So I will have a look at the content of the KDM related config / themes and see if there's any difference.

Rens

(In reply to comment #117)
> Created an attachment (id=508743) [details]
> list of installed rpm's suse 12.2
> 
> 
> after zypper dup'ing from 11.4 to 12.1 to 12.2 
> I now lost the bug.
> 
> perhaps the software list is helpful.
> 
> regards
> 
> rens

(In reply to comment #123)
> I did an patch/fix update on this zypper dup'ed 12.2 install (mentioned below),
> and the bug is back.
> 
> noticeable difference:
> Before the update, the KDM loginscreen looked like TWM: flat, no fancy
> graphics.
> Apparently the normal login SuSE theme was missing or not digestable.
> 
> After that got fixed during the update, it has the openSuSE "branding"

See bnc#781687

Just tried the login config of the KDE desktop configuration app.
on the laptop that "obtained" the bug again after an update:
turning on or off themed login does not make a difference.

Then I switched the style to GTK+
 from <default>

That made the bug disappear, tested 3 times. (*)
I had the files from kdm and kdm-branding backed up.

restoring those, did NOT bring the bug back......

I do not seem to be able to bring the bug back. apparently it is not in the kdm rpm or the kdm-branding-SUSE rpm.........

(*) always did a cold boot: power off, wait a sec, power on.

(In reply to comment #123)
> I did an patch/fix update on this zypper dup'ed 12.2 install (mentioned below),
> and the bug is back.
> 
> noticeable difference:
> Before the update, the KDM loginscreen looked like TWM: flat, no fancy
> graphics.
> Apparently the normal login SuSE theme was missing or not digestable.
> 
> After that got fixed during the update, it has the openSuSE "branding"
> 
> I just upgraded my desktop from 11.4 straight into 12.2 (on a cloned partition,
> thank you very much)
> difference: I had the 12.2 update added as repo, which I did not on the laptop
> upgrade. The bug is not there, everything fine.
> 
> So I will have a look at the content of the KDM related config / themes and see
> if there's any difference.
> 
> Rens
> 
> (In reply to comment #117)
> > Created an attachment (id=508743) [details] [details]
> > list of installed rpm's suse 12.2
> > 
> > 
> > after zypper dup'ing from 11.4 to 12.1 to 12.2 
> > I now lost the bug.
> > 
> > perhaps the software list is helpful.
> > 
> > regards
> > 
> > rens

I realize there are now over a hundred comments on this bug, but it might be helpful if people reporting "new" information read some of them to avoid wasting their own time; e.g., it is already known that the themed greeter behaves differently than the classic one, that the latter will not show up on upgrade systems due to a change in theme naming, that it is restored by a patch, etc.  It is also known that the bug is not in the kdm packages, that Qt is dropping the input between receiving it and updating the QLineEdit, and that there is a mysterious storm of disk activity after the first character, but that all of the characters are being read anyway.

I am sorry I have nothing more useful to report, as I have neither the time nor the expertise to work on the root problem, but it is not a good use of people's time to discover and report the same facts again and again.

I found something in a customer's Xorg log. Is the following of any relevance whatsoever?

Multiple occurrences of key 'UseTheme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc

Regarding comment #127, that is a peculiarity of the way the suse kdm merges configuration data.  Usually it is logged to messages though, not Xorg.  You may also see similar things like "Multiple occurrences of section [General]" and so on.  It does not seem to have anything to do with this bug, since one doesn't even need to use the suse kdm to reproduce it.

I am not able to reproduce this in openSUSE 12.3 Beta 1. Can anybody else confirm?

No, the bug is still there :(

You definitely tested against 12.3 Beta 1? I don't even get a delay now, and the theme is completely new... Can others test this too? This critical bug has persisted across 3 versions now if that's the case...

I applied all the latest updates to 12.2 only a few days ago, and this issue seems to have disappeared/been fixed.

Please note that Malvern Star is suggesting that the bug *may* have been fixed in 12.3.
It is definitely still present in 12.2 - even with all the latest updates.

OK. If somebody can absolutely confirm this bug against 12.3 Beta1 then please move this bug to openSUSE Factory.

I have installed and tested os12.3 Beta 1 on the same hardware, where I originally found and reported this bug. And it is still there.
So move this to Factory.

Made slight change to platform information. Let's hope this will finally get fixed after nearly 2 years.

I installed the openSUSE-DVD12.3beta1-Build0348-x86_64.iso, updated, and I can confirm that the bug is still there :-((

:-))) it seems that in 12.3RC1 it is solved.....veeeeeeerygood work, thanks verymuch to the olimpo guys :-))))))

I cannot reproduce in 12.3RC1. Can anybody else please confirm this, because I didn't have the problem in Beta1 either.

I can confirm that the bug did not appear since I installed 12.3 RC1 (and it was present for me with Beta 1). Hopefully it's gone for good now...

as it's unclear what this is all about anyway, I'm closing it

Has anyone checked that there are no regressions for this against 13.1 M1 or M2?

All fine, 13.1 M2.

I'm pretty sure that 13.1M1 and 13.1M2 are clear of this problem.

I have seen it appear to happen.  However, what has really happened in those
cases seems to be that I have accidentally tapped the touchpad, which has had
the side effect of switching my kdm login to a different user and deleting the
chars already typed.

I liked it better when tapping defaulted to disabled.

It's back with kdm-branding-openSUSE-13.1-5.1.noarch.rpm.

From the changelog:
* Fr Aug 16 2013 bruno@ioda-net.ch
- New kde kdm theme for 13.1

Going back to kdm-branding-openSUSE-13.1-4.6.noarch.rpm resolves it.

@Bruno, Caig, could you take a look at the last comment?

I did some tests and reproduced the issue on a M4 updated to last (yesterday) factory.
Here it seems to be triggered with a first fast login after KDM appearance (but not always :/).

I compared the 12.1 [1], 12.2 [2] and 12.3 [3] themes. According to this page the first two triggered the issue.
I noticed in 12.1 and 12.2 the password entry item is inside a fixed layout node [4], not so in the 12.3.
The current factory theme again uses the fixed node. Maybe fixed node steals the focus (not visually) in some cases?
I tried with a buddy node [5] to force <fixed> to pass the focus to pw-entry in this way [6]. I tried various times and, for now, I'm no more able to reproduce the issue, but way more testing is needed.

[1] https://github.com/openSUSE/branding/blob/12.1/kdm/openSUSE.xml
[2] https://github.com/openSUSE/branding/blob/12.2/kdm/openSUSE.xml
[3] https://github.com/openSUSE/branding/blob/12.3/kdm/openSUSE.xml
[4] http://docs.kde.org/stable/en/kde-workspace/kdm/theme-format.html#fixed-nodes
[5] http://docs.kde.org/stable/en/kde-workspace/kdm/theme-format.html#buddy-nodes
[6] https://github.com/Caig/openSUSE-graphics/commit/e4b904fe89cee128cec1b300cb01e59c94b4a245

Sorry, but what info is needed here for the NEEDINFO status of the bug?

Uhm, according to the faq it seems I had to change the status, sorry, not used to this tool. I hope now it's right.

@Giacomo, could you also open a pull request again the opensuse-branding repo with this bnc number?

Hans-Peter, Neil could you check & confirm if the patch proposed work for you ?

Patched /usr/share/kde4/apps/kdm/themes/openSUSE/openSUSE.xml
And no, it doesn't work.

I wanted to retry, but currently I'm no more able to reproduce the issue on the same previous machine with the not-patched theme and on a new M4 updated to last factory too. :|

Hi,

no more able to reproduce with 4.11.1 packages from KDF.

*** Bug 799481 has been marked as a duplicate of this bug. ***

This bug has appeared for me for the first time after installing the beta version of openSUSE 13.1 on two machines. It did not appear in any of the Mx versions. Installed clean so only one user is available at login - 'root' is now forbidden - so was unable to login via the panel. 

Got round it by:

On one machine I removed tne openSUSE-branded version of the login panel at the online-update stage of installation - not possible at initial software installation stage.

Second machine was not connected to internet so chose 'automatic login' during installation and made the changes to installation once wireless connection was up-and-running.

i had same pb

after first start
then
i attempted several time to login then it fails
then
i had the idea to select the sole displayed user
then
i typed the pwd then kde opened with success a fist session !

after this phenomenon disappeared

but i discovered another pb : root password is not accepted for example to launch yast or root konsole

with rescue mode i changed the root pwd with a very simple one but no success to launch yast or root konsole

i mean i had same pb with 13.1 b1

I tried 13.1 beta, but here issue wasn't triggered.

@Episteme PROMENEUR:
the first time ever KDM doesn't select (no green rectangle) an user (even a single one) because there isn't a previous used one.

@Giacomo Barazzetti

you are right

and there is no pb with root pwd because my iso is bad

i installed again opensuse 13.1 b1 with a new iso then no more pb !

so let's close this.

Let's not! It's still dysfunctional at RC1.

(1) Why can't the first login have a default, highlighted user? If you want lots of users complaining that they can't login after they've installed 13.1, this seems a good way to go about it.

(2) Is banning root login via the openSUSE KDE login GUI official policy now or just an oversight?

>(1) Why can't the first login have a default, highlighted user? If you want
>lots of users complaining that they can't login after they've installed 13.1,
>this seems a good way to go about it.

(above quoted from comment 161)

I agree with that point.  I wonder if it would be better to open a new bug report on that.  I'm inclined to see it as a different problem.

This bug report is about a long lasting unpredictable KDM issue totally unrelated with the KDM bug you are talking about.

Bug 841719 is about that (13.1 will have the same visual workaround used in the previous releases to "fix" it).

Graham Davis said "(2) Is banning root login via the openSUSE KDE login GUI official policy.."
what??? I usually have a root graphic login user, does it will be forbidden in 13.1??
ciao, Pier :-)

(In reply to comment #164)
> Graham Davis said "(2) Is banning root login via the openSUSE KDE login GUI
> official policy.."
> what??? I usually have a root graphic login user, does it will be forbidden in
> 13.1??
> ciao, Pier :-)

My understanding of this according to comment #159 is that the root login failure was caused by a bad iso image.

(In reply to comment #165)
> (In reply to comment #164)
> > Graham Davis said "(2) Is banning root login via the openSUSE KDE login GUI
> > official policy.."
> > what??? I usually have a root graphic login user, does it will be forbidden in
> > 13.1??
> > ciao, Pier :-)
> 
> My understanding of this according to comment #159 is that the root login
> failure was caused by a bad iso image.

The problem I had was that 'root' wasn't in the user list. I looked at [System settings => login screen => users] and saw that 'root' wasn't ticked as an 'excluded user'. Unfortunately, I assumed that this meant that it wasn't an excluded user. However, I've just experimented and found that by ticking 'root', saving, and then removing the tick and saving again, 'root' will then appear on the list of users. Don't know why I didn't think of something so obvious before.

Hello,
I made an inquiry about this and got an answer. --Glenn

http://lists.opensuse.org/opensuse-factory/2013-09/msg00236.html

if you really need to login as root (can't you use root privilege from
an user session?) you can:
* show root in the user list via "System Settings -> Login Screen ->
Users" and deselecting root from the "Excluded Users" list
* or disable the user list in the same dialog tab deselecting the
"Show list" option. >>>> Note: don't enable Autocompletion option.

yes, is what I have done until now, I was warried that this possibility wasn't anymore active in 13.1..:-) :-)

(In reply to comment #167)
> Hello,
> I made an inquiry about this and got an answer. --Glenn
> 
> http://lists.opensuse.org/opensuse-factory/2013-09/msg00236.html
> 
> if you really need to login as root (can't you use root privilege from
> an user session?) you can:
> * show root in the user list via "System Settings -> Login Screen ->
> Users" and deselecting root from the "Excluded Users" list
> * or disable the user list in the same dialog tab deselecting the
> "Show list" option. >>>> Note: don't enable Autocompletion option.

As I pointed out in #166, this won't work exactly as described since 'root' can't be deselected as it's not initially selected. At least, that's what the display wrongly suggests. Under the hood, it seems 'root' is selected so you have to select it first from the GUI so as to get it in line with what is the actual situation. After selecting 'root' and saving, you can then deselect it and get it displayed on the login list.

As to the suggestion that you can use root privilege from a user session, this is indeed true but, on very rare occasions, the result may not be the same. For example, I have found that controlling sound as a user with root privileges does not always give the correct result and logging on as 'root' is the only way to fix it. Also, if your user session display is dysfunctional through, say, a KDE upgrade screw-up logging on as 'root' and reversing the offending change may be the easiest way out unless you are wholly familiar with command language.

Please don't hijack this bug!
Please open a new one or reopen an existing one that relates to your issues.

Thanks.