Description of problem:
Every time when I am trying to log on a text console on a non-root account,
and when running 2.6.14-1.1639_FC5, I see the following:
KDGKBSENT: Operation not permitted
KDGKBSENT failed at index 0:
This does not happen when I am logging as root or if I am running my
previous installed kernel, i.e. 2.6.14-1.1635_FC5 or earlier. AFICT these
error messages do not register in any logs or in dmesg buffer but only on
I do not see, so far, any harmful consequences beyond annoyance but in that
form this is something clearly new.
Version-Release number of selected component (if applicable):
Rechecked with 2.6.14-1.1644_FC5 and no changes.
me too on x86_64 with kernel-2.6.14-1.1651_FC5
With kernel kernel-2.6.14-1.1663_FC5 I see now probably more informative
(although this is probably a result of a new version of 'kbd' package)
Keymap 0: Permission denied
Keymap 1: Permission denied
Keymap 2: Permission denied
KDSKBENT: Operation not permitted
loadkeys: could not deallocate keymap 3
and these indeed can be repeated by a 'loakeys' run from a non-root account.
The catch is that nowhere in my startup files, AFAIK, I am trying to run
'loadkeys'. So this may be a user-space issue caused by limiting some
operations allowed by a kernel but who is really the culprit? 'login' itself?
"KDSKBENT" message does not seem to be coming from 'loadkeys' although the
other most likely are.
I see this too with kernel-devel-2.6.14-1.1682_FC5 and kbd-1.12-11.
I also confirmed this error output on 2.6.14-1.1696_FC5, when I log in as
I added a debug printk that prints the app name when that ioctl fails due to
EPERM. It's definitly loadkeys. It does it 4 times for each login on my testbox.
I've no idea what's actually calling /bin/loadkeys.
Reassigning to kbd maintainer, who hopefully has some clues.
Mitr, that ioctl is no longer valid to be called as a regular user.
/bin/loadkeys is used by /bin/unicode_start like this:
# Change the keyboard mapping in such a way that the non-ASCII keys
# produce UTF-8 encoded multibyte sequences, instead of single bytes
# >= 0x80 in a legacy 8-bit encoding.
dumpkeys | loadkeys --unicode
/bin/unicode_start is called by /etc/profile.d/lang.(c)sh like this:
if [ -n "$LANG" ]; then
case $LANG in
if [ "$TERM" = "linux" -a "`/sbin/consoletype`" = "vt" ]; then
[ -x /bin/unicode_start ] && /sbin/consoletype fg &&
unicode_start $SYSFONT $SYSFONTACM
/bin/unicode_start is a shell script. Maybe it is enough to do there
[ "$(id -u)" = 0 ] && dumpkeys | loadkeys --unicode
to guard that line? It looks that this solves the problem.
*** Bug 174677 has been marked as a duplicate of this bug. ***
I have simply removed the dumpkeys | loadkeys line in kbd-1.12-12; rc.sysinit
uses (loadkeys -u) anyway.
Thanks for your report.
*** Bug 174850 has been marked as a duplicate of this bug. ***
This began to happen because users being able to modify the local console keymap
is considered a security problem. So the kernel was modified to stop allowing
users from doing it, thus the messages. see BZ#172357