TTY has no key for T and i, why?

When I’m in tty (bash),
the letters/keys T and i do not work. Luckily, there is no T in pacman,
No idea where to look for a solution, my laptop just beeps out on it.
Therefore I can not exit the session either or rebooT from it.
Anyone know a good IT assistant… :scream: ?

Obviously, you’ve got a hardware problem. Perhaps clean out the keyboard, or have it replaced.

you can always type
and then hit TAB
to have the shell autocomplete the command :nerd_face:


Hm, they work very fine elsewhere.
Don’t think there’s a mechanical problem, hence the beep to confirm the key press?
Maybe other keys beep out as well, I have not tested.

No. :nerd_face:

yes, I noticed that, but too late
it wasn’t really meant as a solution

have a look at /etc/vconsole.conf
perhaps there is a wrong keymap set?


You’re absolutely right when I open that file with kwrite in Konsole:

Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.

And KEYMAP=de is set there but that is correct…

I did however change paper size in KDE settings.

locale                                              ░▒▓ ✔  22:24:44   ▓▒░
locale: Cannot set LC_ALL to default locale: No such file or directory

Now that I changed the two non-defaults above back in SystemSett.,
the bug still persists. It is only key T+i not working.


kwrite is not complaining in Konsole anymore though.
I have rebooted,

exec zsh
and T and i work. Maybe need to have a look at my modified ~/.bashrc.

Try this to get the content displayed
cat /etc/vconsole.conf

and this to edit
sudo nano /etc/vconsole.conf

I have this in that file:


that is a proper definition of a keymap

1 Like

Can you try to type a different username on login including both t and i?

If that is possible you should also try to log into root and check there.

If those two things work, it would confirm that the issue is related to your users bash settings.

1 Like

here is mine for reference

# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.

I did actively add the german xkb to tty, otherwise the default is only english, regardless of the settings in gui. And it is still not the real german kbd, it has no umlauts, but that is fine cause no linux command has them and at least the z and y keys are correct.

1 Like


umlauts (ä,ö,ü) work in TTY (they are on my german keyboard)

1 Like

Thanks Nachlese, i will try.
@1efaf7d71a8637c6800a to sort out a hardware problem, you can try showkey (install it first) on the tty (it will not work in gui !). For reference the keycodes:
t is 20
shift is 42
i is 23
I do not know if that is of any help.

1 Like

This forum should win a price for its energy. You put in the most random issue on a Sunday night and seconds till minutes later four people have begun supporting.
<3 love you guys!

1 Like

You can also try it with a different Keyboard, I did have a similar problem with G11 Logitech.


It was already installed and not sure what package it is.
Yeah it gives me 23 and 20 so all fine.

Trying with default .bashrc and the problem persists. Guess I will just exec zsh everytime on tty for now.

I did copypaste your vconsole.conf and rebooted, @Nachlese.

Are there any other tty settings that I might look at?

If it works everywhere in GUI
and in TTY as well when using zsh - but not in bash
it’s not a hardware issue

you could have accidentally modified your /etc/profile
(but I guess this would also affect zsh - not sure)

you could compare the default files in /etc/skel with the ones in your $HOME

diff ~/.bashrc /etc/skel/.bashrc

diff ~/.bash_profile /etc/skel/.bash_profile

anything that comes up is a difference you should look at

1 Like

As I had taken my default .bashrc back to test this, they were identical.
My ~/.bash_profile contained my aliases.
Now I backed those up,
cp /etc/skel/.bash_profile ~/.bash_profile && reboot
but the issue’s still there.

Maybe the bug stems from some kind of veiled permission issue, as this bashrc and _profile came from my other computer and were created by a different username. However, now everything should be back to default with the green prompt (that I had made white), too.

based on this message:

which should not be there:
are all the needed locales being generated?

grep -v ^# /etc/locale.gen

it should probably at least give these three:

de_DE.UTF-8 UTF-8
en_US.UTF-8 UTF-8

if not, edit /etc/locale.gen and uncomment what is needed
then run sudo locale-gen

1 Like
grep -v ^# /etc/locale.gen                          ░▒▓ ✔  22:49:27   ▓▒░
zsh: bad pattern: ^#

in bash (btw in Konsole I have no T and i either with bash)

grep -v ^# /etc/locale.gen

en_US.UTF-8 UTF-8

^ at the very bottom, “enabled by Calamares”

Did what you suggested and uncommented the 2, but
is not present so I will add it, right under the other comments.

Ran sudo locale-gen:

Generating locales...
  de_DE.UTF-8... done
  en_US.UTF-8... done
  C.UTF-8... done
  en_US.UTF-8... done
Generation complete.

And same issue in Konsole. Will reply once more if it’s fixed after a reboot.

Seems odd that it’s generating en_US.UTF-8 twice, by the look of it. :thinking: This might be a clue?

The command lets you scan quickly for all the enabled locales.
What it does is, it lists all the lines in that file which do not begin with a # sign
(all the active lines, all the lines which are not commented out)

Just as you, I used this in bash (my default shell) -
I cannot see a reason why zsh would interpret this differently / why it would show you the error.
But I don’t use zsh, so: I’ll likely never know.

But there are usually only a few locales enabled - and the installer adds them to the tail end of the file.
So: you can just:
less /etc/locale.gen
and scroll through and look or use the search function

likely enabled twice - once in the midst of the list and once added to the end of the file.
It’s just a little waste of time, the same locale is generated twice.
Same as if you ran the command two times …