Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#9521 - Luks encrypted root doesn't accept keys (padlock-sha/-aes)
Attached to Project:
Arch Linux
Opened by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 00:53 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 03 March 2008, 22:45 GMT
Opened by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 00:53 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 03 March 2008, 22:45 GMT
|
DetailsDescription:
When unlocking lucks encrypted root the key was not accepted. Only a key on an extern medium unlock the device. Additional info: * package version(s) kernel26-2.6.24.1-2 * config and/or log files etc. Direct after/during key requestion: padlock: VIA Padlock Hash Engine not detected modprobe: WARNING: Error inserting padlock_sha (/lib/modules/2.6.24-ARCH/kernel/drivers/crypto/padlock-sha.ko) After init, when loading modules, same WARNING again, but with padlock_aes/padlock-aes.do Maybe an alias mismatch?: grep padlock modules.alias alias aes padlock_aes alias sha256-padlock padlock_sha alias sha1-padlock padlock_sha alias sha256 padlock_sha alias sha1 padlock_sha All aliases are with underscore than an hyphen Or an hyphen/underscore mismatch in encrypt hook in mkinitcpio? Steps to reproduce: |
This task depends upon
Comparing old kernel 2.6.23 /lib/modules/kernel/crypto shows, that the wer modules named:
aes,sha1, sha256. In 2.6.24 these modules are renamed with an *_generic (aes_generic.ko)
During 2.6.22/2.6.23 these key was always accepted, but not on 2.6.24. Any changes in default NLS keymap maybe.
I added a new key (lucky that i have a key on an extern medium to to this, cause the default key was also not accepted when typing in an de_DE.utf8 console). New key is without locals chars and this works.
The WARNING messages are still in dmesg, also when unlocking with the new key or per extern medium.
Maybe you have a look on this, there must be an reason when my default key wasn't accepted.
Also in MODULES line in mkinitcpio.conf i have "nls_cp437 vfat". These must be autodetected and inserted maybee during use of an usb storage.
I'am my own fool to use foreign chars (and AltGR-Keystrokes) in my Passphrase. As i setup the system i set initial keys
in the installer shell. I think i set the keymap with km there, but im not sure.
Current i've tested in tty unlocking/add new key with several LANG= values, but my old key isn't accepted anymore.
I've added a new key in tty-console (de_DE.utf8) with foreign chars (umlauts). This key is accepted for unlocking during
boot.
I think my initial typed key during setup was malformed. And a wonder that it was working under 2.6.22/.23.
But if i haven't not a rescue kernel on HD and a extern key then i would have a big problem (Hm, booting from
install iso-cd and luksOpen maybe still also work).
From my side i could not anymore say: this is a bug. Seems more like an housemade problem.
If you do not see somthing which is or could be a problem with encrypt from my problem side: close it!
I don't see an gerneral bug, the warnings during boot will sure go away next releases.
And it seems that no one like me have had this problem.
I've changed my keys, live goes on....
There seem to be several people reporting it:
http://bbs.archlinux.org/viewtopic.php?id=43705