Environment: System with crypt_swap and a key stored on sdc (usb) Actual Results: On booting genkernel reports: "Failed to open LUKS device ${LUKS_DEVICE}" Even though cryptsetup actually mapped the partition!!! I consequence I get prompted for LUKS_DEVICE, KEY and KEYDEV. Expected Results: No false Error
Created attachment 286925 [details, diff] genkernel-fix_false_luksOpen_error.patch The proposed patch fixes initrd.scripts with the false error from appearing. The error appears due to splash set_msg exiting with $?=-1 and thus getting captured after crypt_filter function evaluation at line:872 Many thanks for applying this patch or any similar.
Commit f3e0797d42ff2e0a9066a6364b1e063da9679651 makes impossible to evaluate the return value of crypt_filter() at the calling position 862 in initrd.scripts 861 # At this point, keyfile or not, we're ready! 862 crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}" 863 if [ $? -eq 0 ] 864 then 865 good_msg "LUKS device ${LUKS_DEVICE} opened" ${CRYPT_SILENT} 866 break 867 else 868 bad_msg "Failed to open LUKS device ${LUKS_DEVICE}" ${CRYPT_SILENT} 869 DEV_ERROR=1 870 KEY_ERROR=1 871 KEYDEV_ERROR=1 872 fi It might be better to integrate the functionality directly without function call.
Created attachment 291387 [details, diff] Fix bogus LUKS open error The proposed patch could use improvement on the self-explanation front. Please test my proposed replacement. Branch "383545" also holds this patch.
Hi Sebastian Thank you very much for your fix. It provides a small and elegant solution, much better and easier than I could imagine. I tested it and it works as supposed. You may integrate it to the branch. Thanks a lot!
Thanks for testing! Branch "383545" has been merged, genkernel 3.4.20 has been released and added to the main tree: +*genkernel-3.4.20 (08 Nov 2011) + + 08 Nov 2011; Sebastian Pipping <sping@gentoo.org> +genkernel-3.4.20.ebuild: + Bump to 3.4.20 + Closing.
Thank you very much, I got 3.4.20 already!
