Peter_22@xxxxxx wrote: > Then I just thought why LOADNATIONALKEYB doesn´t accept a value like > "de_DE" or "us" Because location of keyboard mapping files varies from distro to another. Finding the right file for one distro is easy, but finding the correct file for all distros is difficult. > and why the script doesn´t run a "dumpkeys >/tools/default.kmap". Because the computer where the initrd.gz is created is not necessarily the computer where it is booted. When you do that manually, you have better control of it at the expense of little extra work. > I am quite puzzled why kernels accept certain parameters like "knoppix > lang=ch|cn|de|da|es|fr|it" to specify a language/keyboard for the console > (http://www.kernel.org/pub/dist/knoppix-dvd/knoppix-cheatcodes.txt) I believe that sets up an environment variable and knoppix init scripts use that variable to load requested keyboard mapping file. > Considering this issue, can I compile the kernel in a way to > enable above "Knoppix-cheatcodes" for the passphrase of loop-aes as well? > Remember, I have built-in some language specific kernel options for the > FAT filesystem to boot from USB already. So, how does the kernel and > loadkeys sit together at passphrase promt? Keyboard mapping file contains info of how to interpret keyboard scan codes. loadkeys program transfers that info to kernel driver. It is possible to pre-compile that info to kernel driver. Last time that I looked at it, doing that involved changing/patching the kernel sources. > In addition a question to UUID in connection with removable storage. I > used to build two or more initial ramdisks since my motherboard´s BIOS > addresses SATA devices with /dev/sda and /dev/sdb and then goes on with > usb-storage devices. So when I change the number of SATA drives I need > another initial ramdisk because the usb-stick changes from /dev/sdb to > /dev/sdc an such. Might it be a good idea to use UUID to have "/lib" for > loop-aes always in the right place? Can the build-initrd.sh script compile > an initrd using UUID or will this conflict with library issues at boot > time? I just thought about it as Kubuntu makes use of UUID and for people > operating usb-hard drives the situation might look even more weird. I hope that you understand that the UUID thing works only on unencrypted partitions. For encrypted partitions, the file system superblock is encrypted, and probing will always fail. My personal opinion is that the folks who made that "go with UUID" decision, made a really bad decision. Probing all devices makes spun-down devices to spin-up, and depending on device type, that annoyance can range from minor annoyance to "accelerated death of the device" [1]. Normal wear and eventual failure in normal use is ok, but anyone who thinks that "accelerated death of the device" is ok because of fucked-up design, must be out of his mind. Peter, If I remember correctly, recent linux kernels include "ub" driver that is sort of dumbed-down version of USB. The main advantage is that /dev/ub* naming does not "mix" with /dev/sd* devices. Disadvantage may be lower performance. Don't know if it works at all, but loop-AES' build-initrd.sh script supports /dev/ub* devices. If you try it, please let me know if it works. [1] Does anyone remember IOMEGA ZIP drives, famous for their click-of-death syndrome? When these drives are probed, they make a click sound when drive moves read-write heads to media, and also similar click when it removes read-write head from the media. Given enough of these clicks the read-write head pops off the metal arm that it is attached to, leading to the famous click-of-death syndrome where drive controller fails to read the media, and keeps re-calibrating / re-clicking the poor thing forever. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD P.S. Guys, if you want loop-AES maintainer (me) to read loop-AES related posts, please CC me. For some reason some of the mails posted to linux-crypto list do not reach me the normal way, but I do check one of the archives from time to time. For example, Markus Reichelt's 16 Jan 2008 15:22:57 +0100 posting got lost, but porn spam flood from few days ago was received ok. :( - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
