Greetings. Being fresh out of ideas regarding the following problem any advise would be much appreciated;
How to enable a USB drive, containing cryptsetup's "--key-file" to unlock the encrypted root partition - whether its on the same (usb) drive or on an other drive (sdX) - during boot, making it unnecessary to physically enter a pass-phrase during the boot process??
What's been tried so far (aside form collecting probably the largest body of "solutions" known to Google, none of which appears to fix this issue, temporarily or otherwise);
Upon building the initrd with the "-K" switch, such as:
mkinitrd -c -k 2.6.37 -r cryptroot -C /dev/sdb2 -w 10 -o usb.gz -K LABEL=usboot:/boot/keyfile.luks
... as an example...
given the "LABEL" [or UUID] variable with the "-K" switch, cryptsetup is unable to locate the "--key-file" and thus proceeds with the pass-phrase prompt to open the encrypted root partition. Once the pass-phrase is manually entered the rest of the boot process is flawless. (Incidentally, we remain unable to boot a system by-label or by-uuid references alone, even when its not encrypted.)
Also, we checked the /initrd-tree/init script line by line and were unable to isolate any obvious issues in the original. (Slack 13.37)
Tested (and encountered the same problem) on the following setups:
Boot Loaders: Lilo, Syslinux, Extlinux (the last being the production system)
Hardware: 12 different BIOS mfrs. [all Intel].
ALL necessary modules are compiled into the kernel (file system -> xfs + all necessary usb drivers etc., in the kernel.)
append initrd=../initrd.gz vga=791
mkinitrd -c -k 188.8.131.52.-generic -r cryptroot -C /dev/sdb2 -w 10 -K LABEL=usboot:/boot/extlinux/lukskey.file -o test-initrd.gz
tried a large number of permutation of the obvious variables, such as the "-w" 5-30 secs.; LABEL=\"part. label\":"/" (e.g. with our w/o the quotes, followed by absolute AND/OR relative path references - and about an other million things, too long to reference all of it here.
However no GRUB, please, as we cant/dont use it - should that be a proposed solution.
Incidentally, the /dev/disk/by-label list devices appear to also have a strange habit of disappearing - seemingly randomly -, especially after particularly simple kernel customizations (like removing audio drivers) and recompiles. (could not isolate it, yet, despite ~20 different kernels built on ~12 different platforms, all seem to be working fine otherwise.)
the "blkid" driver is always present (as is the unbroken util-linux), yet, "by-label" seem to come-and-go. HOWEVER, despite it not being visible, never have any problem referencing the devices by label or uuid in /etc/fstab!!! It all just works. However, one is Not able to reference anything "by-label" in any scripts - obviously?! - when "by-label" decides to just plain disappear. (Someone, please, explain this to us if that person has a free moment. All "expert advice" so far came back the same: "something is broken with kernel/install. Just reinstall.")
Thank you all and help is much appreciated!