Hi, I am using cryptseup-luks for some of my partitions. I noticed that the init script does apparently not support locales. Supposedly because it is beeing started before the keyboard mapping has been set to the proper values by /etc/init.d/keytable. In my example I use a pass phrase which includes a german umlaut (e.g.
Hi, I am using cryptseup-luks for some of my partitions. I noticed that the init script does apparently not support locales. Supposedly because it is beeing started before the keyboard mapping has been set to the proper values by /etc/init.d/keytable. In my example I use a pass phrase which includes a german umlaut (e.g. ü ü as HTML entity). If I mount the partition manuallly after the system has started the key slot can be properly unlocked. On system startup unlocking through the init script (same pass phrase) fails. As I found out this is because of usage of umlauts. Keys not using umlauts work fine. Reproducible: Always Steps to Reproduce: 1. assign a key with e.g. german umlauts to a dm-crypt device 2. unlock the device at the shell -> works fine. 3. reboot, try to unlock the device using the init script -> does not work repeat steps 1 to 4 with a key without any characters requiring locales and everything is fine. Actual Results: could not access my encrypted disk. Expected Results: unlock the key of the ecorrect pass phrase is provided. :) Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r3, 2.6.15-rc1 i686) ================================================================= System uname: 2.6.15-rc1 i686 AMD Athlon(tm) XP 3000+ Gentoo Base System version 1.12.0_pre10 distcc[17968] (dcc_mkdir) ERROR: mkdir /var/tmp/portage/.distcc/state failed: No such file or directory [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.2.3-r5, 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -fstack-protector" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -fstack-protector" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://mirror.uni-c.dk/pub/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.nyx.hu/gentoo" LANG="de_DE@euro" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext S3TC X acl acpi acpi4linux alsa apache2 apm arts artswrappersuid audiofile avi berkdb bitmap-fonts bluetooth bonobo bzip2 cairo cdr crypt css cups curl dga directfb divx4linux dts dv dvb dvd dvdr dvdread eds emboss encode esd ethereal evo exif expat fam fat fbcon fbdev ffmpeg firefox flac foomaticdb fortran freetype gb gcj gd gdbm gif gimpprint glut glx gmp gnokii gnome gphoto2 gpm gstreamer gtk gtk2 gtk2i gtkhtml guile hal hbci icq idn imagemagick imap imlib java javascript jikes joystick jpeg junit kde kdeenablefinal kdexdeltas lcms libcaca libg++ libwww logitech-mouse mad madwifi maildir mikmod mmx mmxext mng moneyplex motif mozilla moznocompose moznoirc moznomail mozsvg mp3 mpeg ncurses network nforce2 nls nptl ntfs nvidia oav offensive ogg oggvorbis openal opengl pam pcre pdflib perl pic pie png pnp ppds python qt quicktime rdesktop readline recode reiserfs rtc samba sdl silverxp slang speex spell sse ssl svg tcpd threads tiff transcode truetype truetype-fonts trusted type1 type1-fonts udev usb userlocales v4l v4l2 videos vorbis xine xml xml2 xmms xv xvid zlib linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS
The reason that i don't believe that this can be done is that the locales that you want to load would have to be loaded after the partitions are unencrypted, this leads to the catch 22 of how do you unencrypted them before you unencrypt them :) My suggestion is to only use natively supported characters in your password. I am open to suggestions as to elegant ways to fix this, however, none leap to mind for me.
Hi, > The reason that i don't believe that this can be done is that > the locales that you want to load would have to be loaded > after the partitions are unencrypted [...] First of all, for me "resolved cantfix" is ok but I do not fully agree - or I just didn't really get it ;-). Is see two general possibilities how to solve it: a) "locales" are stored on an *encrypted* partition (e.g. / or /usr partition is an encrypted volume) b) "locales" are stored on an *unencrypted* partition (eg only /home is an encrypted partition). b) is *no problem* because / and /usr are unencrypted and will even probably already be mounted before dmsetup starts! (erm, actually we're just running through the init scripts, right?) Hence, all we would have to do is just what the locales init script does, that is *setting* the correct locale before the dm-setup takes place and the user is asked for the key. a) might be a problem, yes. On the other hand: for an encrypted root disk an initrd will be necessary anyways. We would just have to add locales to this initrd so that they can be set before one has to enter the key. beyond solving or not: Also keep in mind that currently not only one can not use e.g. umlauts in keys but also the keyboard mapping is currently different between the init script and a normal console! German keyboards use QWERTZ instead of QWERTY layout. I did not test this but if someone uses (sets) a key on onsole with a "z" then during boot he will always end up entering "y" instead of "z" for his passphrase -> which will fail without him even knowing why! Possible solutions: I assume that Gentoo's (luks) dm-crypt could "support" locales either by saying: - "we do not support locales so just don't use any strange keys AND in your mind use a US-Keyboard keymapping when you enter the key during bootup (but not after the system booted)" (huh*) - "locales are supported as long as you do not use this for encrypted root disks. (explanation, "*bla* can't set locale *bla* not mounted *bla* chicken egg *bla..." - or it should be possible to fully support locales in keys by storing all locale files or just the neccessary ones in the initrd. I will seem how much time I'll find and maybe fix this myself. For me a) is relevant (cause I just use encrypted stuf for swap, /tmp and /home) so this should be really quite easy. Personally I can also perfectly live with the situation as is. To sum up: personally I don't depend on it but I disagree that it would generally not be possible to fix. Beyond the question of whether changing the current behaviour or not I think it would make sense to clearly *document* the current caveats...
(In reply to comment #2) > First of all, for me "resolved cantfix" is ok but I do not fully agree - or I > just didn't really get it ;-). > > Is see two general possibilities how to solve it: > > a) "locales" are stored on an *encrypted* partition > (e.g. / or /usr partition is an encrypted volume) > b) "locales" are stored on an *unencrypted* partition > (eg only /home is an encrypted partition). > > b) is *no problem* because / and /usr are unencrypted and will even probably > already be mounted before dmsetup starts! (erm, actually we're just running > through the init scripts, right?) not quite. The cryptsetup-luks script is called before any partitions are mounted (except / depending on how you do it) so that ALL the locales stuff needs to be available at that point. As that is not the case, ie locale support tends to have things installed in /usr, then the cryptsetup scripts can't access it to support it. > > Hence, all we would have to do is just what the locales init script does, that > is *setting* the correct locale before the dm-setup takes place and the user is > asked for the key. This is the entire problem, there is basically nothing before this step. > a) might be a problem, yes. On the other hand: for an encrypted root disk an > initrd will be necessary anyways. We would just have to add locales to this > initrd so that they can be set before one has to enter the key. which will work fine, but how will you UNencrypt that root disk? My point is that you have to UNencrypt the disk BEFORE you can access the locale stuff that you want. This is the problem. > beyond solving or not: > Also keep in mind that currently not only one can not use e.g. umlauts in keys > but also the keyboard mapping is currently different between the init script and > a normal console! > I understand your frustration and the problem, I just don't see an easy fix. > Possible solutions: [snip] these were not constructive. > I will seem how much time I'll find and maybe fix this myself. Please let me know what success you have. thanks for the feedback.
Ok. Thanks for your feedback/explanations. :-)
