Cannot use certain keys in SSH (Pi2)

SSH from a Windows 7 box, on same ethernet network, using PuTTY

That won’t affect the console locale.

Try another SSH client, preferably from a Linux system

No other linux machines in household.

Live Linux Distro.

Also, why would the SSH client have anything to do with the local console also doing the same thing? Like THEM said, it sounds STTY related.

Grabbing puppy to try on a USB stick locally.


use the live linux distro on your pc and test via ssh to the rpi.

Yes, that’s what I mean, booting from a USB.

Alright. Having booted from Puppy Linux Slacko-6.3 64-bit, connecting to ssh via the console shell, I can enter the osmc user and password, but cannot use c or s.

Those are the ONLY keys with a problem.

Still trying to think of what could possibly cause that behaviour …

Few more questions:

  1. Same with ‘S’ and ‘C’? Or is it just the lower-case versions?
  2. If you type some random (‘s’ and ‘c’ less) carp, then try [Ctrl]C, does it “interrupt” (drop you back to the next line with a shell prompt again)?
  3. Have you changed the shell? Again, just groping for ideas here; you obviously can’t type “echo $0” because of the lack of ‘c’, but you should be able to type something else and get an error; E.g. “dd if=$0”? What does that report as the file it fails to open?
  4. Does it make any difference if you type a backslash (\) before pressing a ‘c’ or ‘s’? How about 2 or 3 backslashes?
  5. What’s the output of “env”?

As I say, really fumbling around for ideas here - hopefully answers to those questions might make me think of something …

Fantastic Questions!

Capital S and C both work, lowercase s and c do not.

CTRL+C did an interrupt, cancelled input of text I was typing and went to newline shell prompt.

dd: failed to open ‘-bash’: No such file or directory

-bash? What the hell?

Backslash produced no change in any count.

SSH_CLIENT= 49579 22
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd =40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=0 1;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.l z4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;3;31:.z=01;31:.Z=01;;31:.gz=01;31:.lrz=01;31:.lz=01;31:* .lzo=01;31:.xz=01;31:.bz2=01;;31:.tbz=01;31:.tbz2=01;;31 :.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=0 1;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01; b=01;31:.jpg=01;35:.jpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35 :.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png= 01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;;35:.mpg=01;35: .mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=0 1;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.r m=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;;35: .dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.axv=01; 35:.anx=01;35:.ogv=01;35:.ogx=01;35:.aac=00;;36:.flac=00;36:.m4a =00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36: .ra=00;36:.wav=00;;36:.oga=00;36:.spx=00;36:*.xspf=00;36:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/u sr/osmc/bin:/opt/vc/bin

Oh, and keyboard works completely within the GUI.

Why thank you, kind Sir :slight_smile:

Fortunately, ones which might have shed a little light … Oh, but first:

“bash” - “Bourne Again ‘sh’” - a typically (bad) Unix pun on the name of the author of the original Unix “sh” shell (Stephen Bourne). The ‘-’ at the beginning signifies that it’s a login shell, not one started by typing (for example) “bash” - makes it nice and easy to find the top-level shell in a “ps” listing.

Meanwhile, back at the ranch …

So it is literally, and quite specifically, lower case ‘s’ and ‘c’ characters which don’t work - any other modifier (E.g. [Shift] or [Ctrl]) works fine.
What’s interesting (now) is the “LC_ALL=C” in the “env” output.

So, a few more (hopefully equally fantastic :slight_smile:) questions, but with a massive disclaimer:
My Unix (etc.) knowledge is predominantly mainstream, not Linux; what I’m about to suggest works on mainstream Unix but may or may not work here (though I believe the Linux authors have implemented this sort of functionality, esp. since “stty” on OSMC appears to support lcase (xcase, iuclc and ouclc, more particularly …) …

For the moment, let’s forget “ssh” - what we need here is a console. So follow the guide (as you obviously already have) and hit [Esc] and/or [Shift] and/or [Meta][Alt][CokeBottle] - whatever it takes to get a login prompt on your screen with a keyboard connected.

Test 1:

Hit [CapsLock] (yes, seriously - this is one of those very rare occasions where you actually get to use it properly! :slight_smile:).
Login using the username OSMC, and password OSMC.
If Linux properly implements getty (the historical process handling logins like this), you’ll get presented with your usual shell prompt but with any letters in UPPER CASE.
If so, at this point, you can enter any command you want (including those needing ‘s’ or ‘c’ characters) - it will appear in upper-case, but will be treated as though you entered it in lower-case. Obviously you’ll have a little difficulty with anything which needs upper-case, but let’s not worry about that for the moment …

Test 2:

Log back out again ([Ctrl]D should do nicely …).
Turn off your [CapsLock] :slight_smile:
Log back in again, using a “username” as follows:

osmc LANG=en_GB.UTF-8 LC_ALL=en_GB.UTF-8

(you’ll probably want to copy’n’paste that).
See what happens then. I’m hoping that things then work for you.

While you’re checking that, I’ll go and check something on my “Vero 2” here …

I think I may have found it.

On a whim I looked up this issue in google, not related to osmc but bash.

Some unrelated topic about having a misformed inputrc - I checked my /etc/inputrc by downloading through SFTP, several times (i’m sure it’s not network data corruption because nothing else has come off of there corrupt).

It is FRAUGHT with errors, corruptions, misspellings, things that lead me to believe my SD card corrupted and the inputrc is bad - including a line:

c$do not bell o. tab-completiol

How much you want to bet other files are corrupted as well?

Time to nuke and rebuild. I consider this a case of my system being corrupted.

1 Like

Unless this is expected behavior with lots of ) and weird letters and nulls sprinkled about an /etc/inputrc.

Though I like your test idea.

1 Like

Or you could completely ignore everything I just typed and do a re-install :slight_smile:

Well done on cracking it! :slight_smile:

I don’t mean to ignore what you just typed - I was typing my thing as you were posting yours.

I have not started on the re-install yet, if you’d like I could continue but do you think the /etc/inputrc could be the cause?

1 Like

Can’t remember; would have to look it up (though I can’t see anything even remotely like that in mine - just quickly checked). However, if you can figure out some way to type a ‘c’, then “cat -v /etc/inputrc” (or do it on your newfound boot-from-USB Linux distro, of course :slight_smile:) and you won’t get any weird anything - from what you’re saying, it does sound very much as though something has gone massively wrong on your file-system somewhere …

Still, if nothing else, it gave me a chance to remember some login abilities I’ve not had to use for about 30 years! :slight_smile:

I’m very sorry, I didn’t mean that as any sort of criticism - it just amused me that you’d found the problem as I was typing a short essay in as a reply :slight_smile:

yeah. Also, tried with caps lock to get in with OSMC - it wouldn’t accept login with OSMC / OSMC

poo, I was hoping for a more fun solution.

Well, fresh install it is!

1 Like