I have a strange mis-behaviour that occurs on console that I’m trying to figure out:
Typing the password for root login often results in “Login incorrect”
I can login as root, but it sometimes requires that I attempt 3 or 4 times before a successful login is obtained.
Through happen chance (read: as a side affect of me beginning to start to vent some of the frustration that this PITA anomaly inspires in me), I discovered that if I type the password very deliberately (much slower then normally, and with some force upon the keystrokes) I get a correct login in most tries attempted in this fashion
I assure you that no typing errors are being made during the failed attempts. Further, typing normally for any other user login than root does not generate any failures – only root is afflicted by this misbehaviour. Lastly, I can slow the typing down (think one finger typing) for the root attempt, but without any force to the keystrokes, and still generate the failed attempt
It seems that once I do get a successful root login, I can exit the session and then re-login as root with ease (i.e. by typing as I normally would)
The mis-behaviour occurs:
without fail, if I do a console login (i.e append 3 to the kernel boot command), and
somewhat unpredictably if I switch to console directly from the Display Manager screen or
somewhat unpredictably if I do a regular boot into an X environment and then switch to console (any tty) and attempt a root login from there
I’m stumped. Is there some sort of keyboard sensitivity setting for root I’m missing??
This is with 12.2, 64bit, and has been present since day 1 of the installation (just getting around to addressing it). I have never been affected like this, and on this very same hardware, ever before.
No hits in the forum search. Google Kung-fu not working.
So I have had similar issues recently, but I was able to determine it was the number 4 not showing up from the row at the top. Since it was erratic as well, I switched to a wireless keyboard and the problem went away. Only thing, Windows 7 does not like the mouse that comes with it. I use a keyboard monitor switch and I have found everything works just fine when directly plugged in to each PC. I am not really sure what to make of it all, but hardware can fail, at a time and choosing of its own without regard to the fact you recently switched to openSUSE 12.2. I am not sure that this is any comfort to you, but it took me a while to determine it was the number 4 that was not working too well and going slow always works for me as well. I have not decided what to do except I can leave the wireless keyboard and wired both plugged in. The wired mouse works great with Windows 7 and the wireless keyboard works great with openSUSE. I just can’t find a no additional cost fix for this mess. I even have a new wired mouse that works great directly plugged in but does not work at all through my keyboard and monitor switch. So I can only offer comfort so you can know your not alone.
So I am not seeing any complaints about this until yours meaning a software cause is not very common I think. If I felt it was software, I would just reload openSUSE and see what I get, keeping what I need to a minimum the second time around. In my case I decided to to reload to switch to the native nVIDIA driver, but the switch made no difference in my case and anyway I have determined one kind of hardware mix does not have the problem. None the less, I shall keep my eyes open if I should see anyone that says they have the same problem I will surely let you know Tyler_K.
On 10/30/2012 01:56 AM, Tyler K wrote:
> I’m very confident that the issue is a low level software
> one, as opposed to a hardware problem.
previously you wrote: “I discovered that if I type the password … with
some force upon the keystrokes”…which causes me to surmise: the
application of additional force at the keyboard solving your problem
just about proves to me that it is hardware!
because, there is no software in openSUSE (or Linux in general) which
responds to a forceful key press, but not a ‘normal’ key press
on the other hand there are ways to modify the response to the length of
a key press, so if you have fiddled with the systems accessibility
controls (especially by activating “slow keys” or “bounce keys” you may
have inadvertently introduced software response anomalies you didn’t
intend to do…
to remedy that i’d suggest you disable all accessibility controls (use
the “Defaults” button) and see if that solves your problem…
on the other hand, if you are a disabled person and need those special
accessibility services you may just need to retune your settings…
I know what you folks are saying, but I stress that it is NOT a hardware issue per se; software controlling the hardware, yes.
Perhaps I’m not explaining it well enough (which was actually a concern of mine when I typed it up, cause I knew the focus would likely fall upon the hardware). Again, this occurs only under very certain circumstances. It NEVER happens from a terminal emulator, only on console. I’ve switched to root, and supplied root’s password, in a TE literally “oddles and oddles of times” and have never tripped the problem which is encountered on console. The odds that it is a hardware problem alone are astronomically thin given the reproducibility … either that or the computer gods have a very strange sense of humour
because, there is no software in openSUSE (or Linux in general) which
responds to a forceful key press, but not a ‘normal’ key press
exactly the point that makes this pretty bizarre. As password input is not echoed, it is simply impossible to see what keystrokes are not being picked up or are being duplicated … but again – why would this only happen for the root user, and not normal users. Why can I, when inputting the password on console, type normally without fail for them (regular users), but not when as attempting a root login? Why does everything work splendidly in a terminal emulator or gui, but not on console. ?
on the other hand there are ways to modify the response to the length of
a key press, so if you have fiddled with the systems accessibility
controls (especially by activating “slow keys” or “bounce keys” you may
have inadvertently introduced software response anomalies you didn’t
intend to do…
I believe it has been present from moment one of the 12.2 install – though, I’m not 100% certain about that. I have never fiddled with accessibility keys and what not (have no requirement for them), nor can I think of anything that I may have done which would have inadvertently had some impact.
to remedy that i’d suggest you disable all accessibility controls (use
the “Defaults” button) and see if that solves your problem…
on the other hand, if you are a disabled person and need those special
accessibility services you may just need to retune your settings…
I don’t think I’ve ever accessed the accessibility controls (ever). As described, it sounds like you were talking specifically about the KDE module (which I just had a peak at). Gnome’s module is “Universal Access” … (just had a peak at it too). Both of these look tailored to the(ir) respective GUI environment, and for a typical user login. Unless I’m overlooking something, this seems off base, but thanks for the suggestion though.
Hi, perhaps a way to rule out hardware failure would be to create a new (not root) user with the same password as the one you use for root. See if you have trouble logging in for that user, too. Or change the root password, not using any of the letters used in your original root password. HTH Lenwolf
After a couple of minutes of thought, I’ll append the thread to note that “hardware failure” is not quite applicable … again, the root login works perfectly in terminal emulators and gui boxes … if it was hardware failure, one would not see distinguishable behaviour from that observed while on console i.e. if it was hardware failure, I would also see “login incorrect” for root in terminal or gui logins as well, but I don’t
But in any regard, a test of the suggestions should provide some interesting insight
This is about a different problem. It is not asking for help. I am using it to illustrate what can happen.
On a computer that I use at work, the mouse worked fine with opensuse 11.3 and 11.4. It also worked fine with Windows XP. However, when I upgraded to opensuse 12.1, it started to give problems. Specifically, middle click on the mouse wheel sometimes did not work. If I clicked very lightly, it usually worked. If I clicked with more pressure, it did not work.
I am considering that to be a hardware problem. I actually tried a different mouse (also a PS/2 mouse from the same manufacturer) and it had the same problem. My best guess is that it had to do with the debouncing logic in the driver software.
I have since switched to a different computer box, but am using the same mouse. And the problem is no longer there. So part of the problem might be in the logic of the PS/2 port on the main computer board.
Getting back to your keyboard problem. The drivers used for console mode may be behaving differently from those used with a GUI. I would guess that your problem may have something to do with debouncing logic, though that’s a guess.
If the logic works with most hardware devices, but fails with a few, is it a logic problem or a hardware problem? People will disagree over this. But don’t rule out the possibility that you have hardware that is a bit too far out-of-spec.
Thanks. Interesting story which I do think parallels my current experience very well.
As for your guess – yes, that’s what I’m thinking along the lines of – low level console driver logic … though, it seems to be on a per user basis (i.e. affecting only root) rather then a uniform appearance affecting all users.
Anyway, will attempt the earlier suggestions a little later to see if that sheds any more light on the situation
> As for your guess – yes, that’s what I’m thinking along the lines of
> – low level console driver logic … though, it seems to be on a per
> user basis (i.e. affecting only root) rather then a uniform appearance
> affecting all users.
Consider a bugzilla…
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))
yes, but only once I get a better idea of what it might be – right now its more of a needle in a haystack as opposed to anything concrete.
In any regard, I’m putting this (back) on the backburner for the time being – while I find it intriguing, I’ve more pressing/priority things to deal with. Will update accordingly
I get the exact same message when attempting to log in as root: "Login incorrect’. However, I ONLY have this problem when using the Xen virtual console (cli). I don’t have this problem with logging in via the Xen VNC console.
Also, it should be noted that the “Login incorrect” message comes before it asks for a password. It’s immediate after typing root <enter>.
[LEFT]Check your /var/log/auth.log against failed root login. You might find out something similar to these:Dec 30 07:31:51 vps login[18093]: (pam_securetty) access denied: tty ‘hvc0’ is not secure ! Dec 30 07:31:51 vps login[18093]: FAILED LOGIN (1) on ‘hvc0’ FOR `root’, Authentication failureIn modern systems there are lots of new technologies used, and for example XenServer virtualized instance might have console as hvc0.This can be fixed by including that console into /etc/securetty. Just type: echo hvc0 >> /etc/securetty && kill -1 1 Then try login again.
[/LEFT]