So, hier die Anleitung um diese padlock "Fehlermeldung" wegzukriegen. Diese padlock
Module bedienen wohl Entschlüsselungs-Hardware (z.B. Fingerabdruck-Scanner o.ä.),
was wohl die wenigsten zur Verfügung haben.
Versucht zu laden werden die Module an zwei Stellen:
a) in der initrd
b) durch udev
Zu a)
Der encrypt-Hook bewirkt beim Erstellen des initrd-Images das alle Module die in Verzeich-
nissen namens crypto liegen eingebunden und versucht zu laden werden.
Das kann man steuern durch den Parameter CRYPTO_MODULES in der /etc/mkinitcpio.conf
ähnlich des MODULES Parameters dort.
D.h., man muß alle Crypto-Module, die zum Aufschließen der verschlüsselten Root-Partition
nötig sind, dort explizit aufführen da der encrypt-Hook diese nicht mehr automatisch
einfügt.
Die benötigten Module kann man durch lsmod im laufenden System finden. Wer seine
crypto-Module anhand des Namens nicht eindeutig identifizieren kann findet sie auf
diesem Weg:
cd /lib/modules/$(uname -r)
source /lib/initcpio/functions
m="$(all_modules "/crypto/") "
echo $m
Diese Module würde der encrypt-Hook automatisch einbinden (darunter auch die padlock).
Zum Abgleich mit den eigenen Modulen jetzt einfach lsmod mit dieser Liste vergleichen.
Der nötige Eintrag in der /etc/mkinitcpio.conf kann z.B. so aussehen:
CRYPTO_MODULES="blowfish sha256_generic aes_i586 aes_generic"
Jetzt noch das initrd-Image erstellen(als root): mkinitcpio -g /boot/kernel26.img
Zu b)
Damit das Modul durch udev nicht versucht wird zu laden. Es reicht
nicht (bzw. hat
keine Auswirkung) die Module in der rc.conf mit ! vom Laden ausschließen zu wollen.
Erst das explizite Blacklisten bei udev führte bei mir zum Erfolg. Also
# Datei /etc/modprobe.conf editieren
blacklist padlock-aes
blacklist padlock-sha
Diese Änderungen bewirken bei mir, daß die (irritierende) Fehlermeldung beim Booten
nicht mehr auftauchen.