Bugzilla Bug 123270

I'm not sure whether this problem is caused by kernel or mingetty.

I think it was after upgrading to kernel 2.6.14 when I started to get these
messages after login:

Last login: Fri Feb 10 07:47:36 2006 on tty3
Keymap 0: Permission denied
Keymap 1: Permission denied
Keymap 2: Permission denied
Keymap 3: Permission denied
Keymap 4: Permission denied
Keymap 5: Permission denied
Keymap 6: Permission denied
KDSKBENT: Operation not permitted
loadkeys: could not deallocate keymap 7

Then I realized that my unicode setup was still configured according to the old
(wiki) instructions and therefore I still had this in my ~/.bashrc:

if [ $TERM = "linux" ]
then
        unicode_start lat9w-16
fi

So I commented it out only to find out that unicode does not work anymore even
though it should, as it is now set by the init scripts.

I did some googling and found this old kernel thread where mingetty is
mentioned as one of the programs that can reset UTF-8 mode to "off":
http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/0604.html

So far my workaround to this problem has been running 'sudo unicode_start
lat9w-16' from the .bashrc file. However, I really feel that unicode should
work if configured according to the official guide, even if one chooses to use
mingetty instead of agetty.

please test net-dialup/mingetty-1.07.5 and see if it solves the issue.

No, unfortunately the new version does not fix this. It is exactly the same as
before.

I'm sorry but there is little I can do.

The thread you mentioned contains a kernel patch that add
/proc/tty/vt/default_utf8_mode, which really is the wrong way to fix the
problem. It isn't kernel's fault that mingetty fails to re-enable UTF-8 mode
after it resets the console.

Up to now, upstream didn't considered this problem important enough to fix it
(see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155531).

The only mingetty that apparently (judging after their Changelog) have UTF-8
support is the one developed/forked by Suse.

I've ddecided to reopen this bug as I've come across an UTF-8 problem obviously
involving mingetty...

It basically relies on UTF-8 not working in mingetty, working in agetty and my
settings seeming to be correct.

I apologize if you judge this reopening inconvenant  but a discussion on the
Gentoo forum [url]http://forums.gentoo.org/viewtopic-t-517538.html[/url] (where
I gave as many details about my problem as I could figure out myself, and even
a bit more) pointed out to this bug report, which makes mention of a suse
version that would be supposed to work right...

Could it be possible to include suse's modifications, or even use or add their
version to the tree, as mingetty is GPL-2?

My decision remains the same. Until upstream fix it or someone else post a
patch, please use another *getty on Unicode enabled terminals.

The Suse variant of mingetty is a fork of the program developed by Florian La
Roche. Worst yet, is a fork with the same name and without a home page.

From what I see in their source, they don't reset the terminal at all, just
clean the screen. If you are interested, adapt the mingetty-0.9.6s.dif patch
made by Suse to mingetty-1.07, test it and submit the patch here.

Created an attachment (id=102486) [edit]
Changes the way consoles are reset to keep UNICODE. Based on Suse patch.

This patch is based on Suse patch (mingetty-0.9.6s.dif) that is found in
mingetty-0.9.6s-86.src.rpm.

reopen the bug

After a careful study of the source, I came to the conclusion that neither
mingetty nor agetty ever sets the terminal in Unicode mode. The script
responsible of setting Unicode on tty1..ttyn is /etc/init.d/keymaps.

The patch looks OK and works for me. The only thing that bothers me is the
inability of mingetty and login to interpret backspace (if you make a mistake
when typing username or password, you have to go forward and retry in the next
spawned mingetty process).

The patch was included in mingetty-1.07-r1 and is applied only if unicode USE
flag is enabled. 
Thanks!