Mon ordinateur a été interrompu lors de la mise à niveau du 14.04 au 16.04. Après j'ai redémarré et couru
Sudo dpkg --configure -a
et redémarré à nouveau. Maintenant, lorsque je suis invité à saisir mon mot de passe au démarrage, rien de ce que je sais ne fonctionne. J'ai vérifié le verrouillage des majuscules et des touches numériques et tapé avec soin, et je ne me suis jamais amusé avec des claviers différents. En effet, en accédant à GRUB et en y tapant, tout ce que je tape a l’air attendu.
Tenter de quitter le mode de récupération entraîne cet échange:
Please unlock disk sda5_crypt:
(J'entre mot de passe)
Failed to setup dm-crypt key mapping for device /dev/disk/by-uuid/[some numbers]
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
cryptsetup: cryptsetup failed, bad password or options?
Je ne vois pas comment résoudre ce problème (apparent) avec le noyau sans pouvoir accéder à une ligne de commande normale.
Pas tout à fait une solution au problème posé, mais j'ai fini par démarrer à partir d'un ancien noyau où sda5_crypt fonctionnait.
Quand je lance cryptsetup --help à partir d’Ubuntu 14.04LTS, l’affichage suivant apparaît à la fin des options habituelles: -
Paramètres de clé secrète et de phrase secrète compilés par défaut: Taille maximale du fichier de clés: 8192 Ko, longueur maximale de la phrase secrète interactive 512 (caractères) Durée d'itération par défaut de PBKDF2 pour LUKS: 1000 (ms) Paramètres de chiffrement de périphérique compilés par défaut: Loop-AES: aes, clé 256 bits En clair: aes-cbc-essiv: sha256, clé: 256 bits , Hachage du mot de passe: ripemd160 LUKS1: aes-xts-plain64, clé: 256 bits, hachage de l'en-tête de LUKS: sha1, RNG: /dev/urandom
Vous voudrez peut-être vérifier si le module aes est chargé dans votre noyau, en utilisant lsmod | grep aes
http://crunchbang.org/forums/viewtopic.php?id=37276 avait des informations utiles sur les modules nécessaires lorsque l'erreur mentionnée apparaît.
Dans mon noyau, le module noyau/Arch/x86/crypto/aes-x86_64.ko semble le fournir. Il semble que ce soit une partie standard du noyau, donc je suppose que ce n’est tout simplement pas chargé par défaut. L'arbre de dépendance dans/proc/modules sur ma machine indique aes_x86_64 => aesni_intel et aesni_intel ne semble pas avoir de dépendance. Le chargement devrait donc être simple.
J'espère que ça t'as aidé