[conspire] solution: VirtualBox text console keyboard repeat rate way too fast

[Michael Paoli]

So, an issue I, and apparently fair number of others have also run
into.  And kind'a specific to VirtualBox (some other VMs might be
a bit similar, but I haven't seen any as bad as VirtualBox on this
particular issue).

So, you've created a VM.  And you've done it under VirtualBox.
Most seems fine and well ... except one highly annoying issue.
When operating on the (virtual) console ... at least in text mode,
the keyboard repeat rate is way too fast.  Not only is it way too
fast, but its so fast and activates so quickly, that it can make
logging in on the console, if not difficult, darn near impossible!

So, ... search 'da Interwebs, ... various "answers", some of them
useless and incorrect.  Best bit(s) out there:
setterm --repeat off
That disables the repeat on the (virtual) console one is on.
Okay, great ... but Catch-22 - have to login first.  Right?
Almost.  What about fix all the virtual console devices?
And before even attempting login?

Enter the /etc/rc.local file (at least for most(?) Linux distros).
I added to it, the bit below:

[ \
         VirtualBox != \
         "$(
                 exec 2>>/dev/null &&
                 cat < /sys/devices/virtual/dmi/id/product_name ||
                 cat < /sys/class/dmi/id/product_name
         )" \
] ||
(
         # The repeat is problematic (super fast!) on VirtualBox,
         # so turn it off and store that as (session?) default:
         TERM=linux export TERM
         setterm --repeat off
         setterm --store
) |
tee /dev/console /dev/tty[0-9] /dev/tty[0-9][0-9] \
         >>/dev/null 2>>/dev/null

So, what's that do?  Well, first it checks if it's a VM
(yes, that's also very handy - can be done under at least Linux (and
I've done so under Solaris too - but by different means)) ... and
also the manner/type/flavor of VM.  If it's not a VM, or not a
VirtualBox VM, that little test bit returns true (0), and we don't
do the other bits.  However, when that bit gives us VirtualBox,
the not matched to that fails (it did match), and it then proceeds
to run the bits after that (after ||).
setterm apparently (did some testing) uses TERM - and wants a
suitable type for console to output the appropriate codes for
console - and then writes them to stdout.  So, we set TERM to a
suitable type in the environment - we do that in a subshell () to
avoid otherwise "polluting" our environment (in case something might
source (.) /etc/rc.local, instead of executing it), we then run
our setterm commands, and pipe that to tee.  And using tee,
we write to all the virtual console devices (/dev/console might be
graphics text (default), or serial, or even network ... I just hit
it here regardless, but one might test that if it may be a concern),
and toss away the leftover stdout that tee also writes (don't need it,
and don't know where that might end up - could be some log file or
something - don't really need it).  I also chose to discard stderr
there - though one might choose otherwise.

That's pretty much it.  Not quite a 100% solution, ... but close.
On OS I was doing this on, could change keyboard repeat rate and such
for the OS - but that made zero changes to the way the VirtualBox's VM
virtual console would behave, and there are no settings for keyboard
rate in VirtualBox.  So, it's a pretty good "fix" (/workaround), as
it also is effective before login (and often when it's critically
needed before login).  Not quite 100%?  Yeah, might not suffice
if one boots to single user or maintenance mode or the like, or
in some manner where /etc/rc.local doesn't get run ... so still
not 100% ... but pretty close.

I suppose one could put "hook" like that in much earlier,
maybe even something like that in the initramfs.  Still wouldn't
quite be 100%, but maybe closer.  Really a VirtualBox issue that
ought have a virtual hardware fix.  But short of that ...
fairly effective work-arounds.

Other VM flavors?  I've not seen this issue at all with
qemu-kvm and virt-viewer and such.  On ESXi, I've seen it
somewhat ... yeah, sure annoyingly fast repeat ... but not so
dang fast it was near impossible to login, or issue commands
okay (for the most part) after logging in.