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 attachment 102486 [details, diff] 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!
