I use a hardened profile/kernel and utf8/unicode-support and get some errors when logging in with my normal everyday user. (see actual results below) Reproducible: Always Steps to Reproduce: 1. have a fresh hardened installation 2. enable unicode-support like described here: http://de.gentoo-wiki.com/Utf8 3. create a new user profile using the default /etc/skel/ files from the fresh installation 4. log in to that user's account Actual Results: (while .bashrc runs /usr/bin/unicode_start gets called and the command "dumpkeys | loadkeys --unicode" contained in there results in the following error messages:) Keymap 0: Permission denied Keymap 1: Permission denied Keymap 2: Permission denied KDSKBENT: Operation not permitted loadkeys: could not deallocate keymap 3 Expected Results: no error messages ;) i guess it's because the system is hardened. but in that things i'm only a rookie. yesterday my first hardened system was finally installed and i'm in the learning-phase. but i expected stuff that's already in the baselayout to work achtually. ;) here comes the emerge info: Gentoo Base System version 1.6.12 Portage 2.0.51.22-r1 (hardened/x86/2.6, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-hardened-r15 i686) ================================================================= System uname: 2.6.11-hardened-r15 i686 AMD Athlon(tm) Processor dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe -falign-functions=4" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mir.zyrianes.net/gentoo/ http://www.gigaload.org/gentoo.org/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage//packages/x86/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow aalib acl acpi alsa apache2 audiofile bash-completion berkdb bluetooth bzlib chroot crypt cups curl curlwrappers dedicated dio directfb dlloader doc encode exif fbcon fftw flac flash flatfile foomaticdb ftp gd gdbm gif gpm gstreamer hardened hardenedphp imagemagick imap imlib innodb jack java jikes jpeg junit ladcca lcms libcaca libwww mad mime ming mmap mmx mng mp3 mysql mysqli ncurses nls nocd offensive ogg oggvorbis openal pam pcre pdflib perl php pic png portaudio posix ppds prelude python readline ruby samba sdl session shared sharedmem slang sndfile snmp soap sockets sox spell spl ssl svg tcpd threads tidy tiff tokenizer truetype unicode usb userlocales vhosts vorbis x86 xml2 xsl zlib fritzcapi_cards_fcpci linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, PORTDIR_OVERLAY
afaik unicode_start is only for virtual terminals, it isnt used when in X terminals you shouldnt use unicode_start anyways for virtual terminals but rather you should set the UNICODE variable in /etc/rc.conf and update /etc/conf.d/keymaps accordingly
virtual terminals? X? sure you read the bug report?? ;)) I'm not sure what you mean by "virtual terminal", but there is no X on my server. the login is on a normal console. no ssh, no serial port, nothing else. just plain simple normal user login. ssh isn't even installed yet.. /etc/rc.conf and /etc/conf.d/keymaps are configured correctly. no idea what this unicode_start is for. it just was there in /etc/skel/.bashrc and i thought that this had a reason and did not change the file.
sorry but i can't stand this attitude anymore. this is too much! wonderful style of problem handling you have here at bugs.gentoo.org: first: quickly fly over the report. second: answer with something not related to the report assuming things not assumable and never stated by the reporter. third: "okay, don't bug my. it's 'resolved'" this is not the first time i get this kind of answers in bugs.gentoo.org. i worked on some other bugzilla-sites and never got that kind of attitude of "you haven't seen anything! do we understand us? you _haven't seen anything_!". there still are good poeple here for sure. but what happened?? too much dumb poeple creating "bug"-reports where there's only a pebkac and then doing stupid rands missing any logical reasoning? I have no idea, but i'm not one of those. I know the side of bug fixing better than the side of bug reporting because i did for a long time. And I also know that i analyze the problem first, and if it's a pebkac i have to prove it. if not i have to fix it. and if i don't want i should stop doing as if and search for something other to do... but maybe that's only my attitude to expect logical reasoning ald proving from bug wranglers, and bugs.gentoo.org is just a /dev/null with a randomized response action attached to it making it look like those ranting "DAU"s got a new job as "bug wranglers". :(( this will only make the thing more buggy, because everyone will stop reporting bugs when he's called a pebkac-idiot all the time even if he is a who-knows-how-experienced guy...
Spanky gave you a very accurate response. The simple fact of the matter is that 'unicode_start' is not in Gentoo's /etc/skel/.bashrc. You can confirm this by looking at: http://www.gentoo.org/cgi-bin/viewcvs.cgi/rc-scripts/etc/skel/.bashrc?root=gentoo- src&rev=1.12&view=log and http://www.gentoo.org/cgi-bin/viewcvs.cgi/app-shells/bash/files/dot-bashrc?rev=1.3&view=log It appears you picked up the 'unicode_start' from the unofficial gentoo-wiki site. Spanky's response remains very valid, 'unicode_start' should not be used in X terminals (which you are not, since you don't have X installed), nor should it be used in a virtual terminal (which you are). He went as far as telling you the proper way to do what you want. You should not need 'unicode_start' if you do things The Right Way. It's important to note that 'keymaps' should be in your boot runlevel, if it's not, you can run 'rc-update add keymaps default', but it should not be necessary, since it should be there by default.
(In reply to comment #4) > Spanky gave you a very accurate response. Yes. Very accurate, yet cmpleteley useless. ;) Like in this old microsoft joke: http://www.cs.bgu.ac.il/~omri/Humor/MSJoke1.html > afaik unicode_start is only for virtual terminals, it isnt used when in X terminals to associate this to the bug report you have to assume that i use X or virtual terminals. else the statement is completeley useless, because as of my knowledge it does not tell anything related to the report... > you shouldnt use unicode_start anyways for virtual terminals now the assumption that i use a virtual terminal is strengthened. but without a ninformation what base does allow such a (wrong) assumption. >but rather you should set the UNICODE variable in /etc/rc.conf and update /etc/conf.d/keymaps accordingly yes. thank you for the tip. but that's already in the tutorial. not your fault but this also does not solve anything ----- > The simple fact of the matter is that 'unicode_start' is not in > Gentoo's /etc/skel/.bashrc. You can confirm this by looking at: > > http://www.gentoo.org/cgi-bin/viewcvs.cgi/rc-scripts/etc/skel/.bashrc?root=gentoo- > src&rev=1.12&view=log > > and > > http://www.gentoo.org/cgi-bin/viewcvs.cgi/app-shells/bash/files/dot-bashrc?rev=1.3&view=log > > It appears you picked up the 'unicode_start' from the unofficial gentoo-wiki site. Very interesting. Now I have no idea how it came in my /etc/skel/.bashrc... Hmm... maybe some special patch when you enable unicode before reemerging basic stuff like baselayout... Is it safe to delete the whole unicode_start thing in .bashrc? what's with unicode_start itself? Can i also delete the file? I can guarantee i never created it myself, so maybe i serves a purpose... > Spanky's response remains very valid, 'unicode_start' should not be used in X terminals (which you are > not, since you don't have X installed), nor should it be used in a virtual terminal (which you are). As i said above: very valid but completely useless in my case. ;) Why am i in a virtual terminal? is the normal linux login shell a virtual terminal?? Then what is a real terminal? Can it get more real than a terminal straigt on the graphics-card and keyboard of the server? ;) > He went as far as telling you the proper way to do what you want. You should not need 'unicode_start' if you do things The Right Way. Assuming that i use a virtual terminal, wich i did not think as he wrote the response. So without the explanation that i use a virtual terminal this helped me nothing. I could not find the information on the net, explaining me what could be more "real" than what i use... :( > It's important to note that 'keymaps' should be in your boot runlevel, if > it's not, you can run 'rc-update add keymaps default', but it should not be necessary, since it should be there by default. yup. it's there. at least one good thing... so to make it a one-liner: Would it be the right way to remove the unicode_start from .bashrc without any precautions?
About terminal emulation: http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Text-Terminal- HOWTO.html#s9
you need to learn to calm down and drop the attitude ... NOWHERE did i call you an idiot, it seems you're the one who needs to re-read my original response then you need to learn what a virtual terminal is when you log in to your machine via getty at boot, you're using a virtual terminal ... the default Gentoo config is to setup 6 vt's (ctrl+alt+f1 -> ctrl+alt+f2) like i said already, you dont have to run unicode_start because baselayout already does it for you if you set UNICODE=yes in /etc/rc.conf
