Forum Linux.debian/ubuntu [RÉSOLU] Cryptsetup est passé en QWERTY

Posté par  . Licence CC By‑SA.
Étiquettes :
1
22
jan.
2016

Bonjour,

Depuis une mise à jour du noyau de ma Debian Jessie, hier, l'invite de mot de passe de LUKS au démarrage est en QWERTY, et je ne trouve pas comment le changer de nouveau.

C'est la deuxième fois que ça m'arrive. La première fois, c'était après l'installation d'un noyau backporté, que j'ai supprimé pour régler le problème. Ici, je ne me vois pas revenir à un noyau non mis à jour pour faire fonctionner mon clavier correctement.

Je n'ai pas non plus envie d'apprendre à taper en QWERTY, ni de changer de mot de passe.

Quelqu'un sait-il comment repasser l'invite de LUKS en AZERTY ?

  • # Re:

    Posté par  . Évalué à 3.

    Je sait pas si c’est à jour : https://wiki.debian.org/fr/Keyboard#Configurer_la_disposition_du_clavier_dans_initramfs

    Après pour que ça fonctionne, faut que le clavier soit déjà bien configuré dans la console localectl --no-convert set-keymap fr

  • # Version simple

    Posté par  . Évalué à 0.

    Version simple, tu as essayé de réinstaller le vieux kernel?

    Je détaille: sous Debian, sauf mention contraire, la totalité des vieux paquets est conservée, ce qui cause d'ailleurs un sérieux problème de perf quand on n'utilise pas la version stable.
    Si une mise à jour, Jessie ou pas, à pété ton système, tu peux toujours faire un dpkg -i suivi du nom de fichier de l'archive précédente, laquelle sera vraissemblablement située dans /var/cache/apt/archive, ou un truc du genre. TAB est ton amie.

    Je viens de voir ce message, et ça a l'air gênant, alors je répond à l'arrache et en mode sauvage. Je vais de ce pas me renseigner sur ce que je ne connaissais pas (LUCKS, en plus le chiffrement m'intéresse) histoire d'être plus civil et plus précis.

    • [^] # Re: Version simple

      Posté par  . Évalué à 0.

      Bon, j'ai lu vite fait. Je doute d'avoir tout compris, mais… on va essayer de donner des pistes :)

      LUCKS semble être un système de chiffrement de disque. Hum. Disque ou partition? Enfin… admettons disque.
      Quand un PC démarre, c'est d'abord le POST, puis le BIOS prend le relais pour le passer au MBR. Enfin, ça, c'était l'ancien temps, celui que je connaissais vaguement.
      Toujours est-il qu'a ce que j'ai lu, il me semble que le chiffrement nécessite un chargeur de démarrage (boot loader) capable de lire la clé de déchiffrement comme il faut.

      Donc, le problème se pose avant le chargement de linux. Utilises-tu GRUB ou LILO ou autre (et quoi dans ce cas?)? Utilises-tu un BIOS avec secure boot?

      Si jamais le problème n'est pas le boot, il semble que le module chargé du déchiffrement soit dm-crypt. Je doute que ce soit lui qui lise l'entrée clavier, donc il faudrait savoir qui lui donne à manger. Je ne peux pas vraiment aider plus, navré.

      • [^] # Re: Version simple

        Posté par  . Évalué à 1. Dernière modification le 23 janvier 2016 à 01:07.

        De Wikipédia :

        LUKS, pour Linux Unified Key Setup, est le standard associé au noyau Linux pour le chiffrement de disque créé par Clemens Fruhwirth.
        Je ne sais pas exactement qui fait quoi, mais je crois que LUKS est un format de partitions chiffrées. Le chiffrement est géré par le module dm-crypt de Linux, qui permet de chiffrer des "block devices" (comme /dev/sda1, je ne connais pas de traduction). Donc ça peut être une partition ou un disque entier.

        Je crois que sur mon PC, le démarrage ressemble à : UEFI, GRUB, kernel Linux. Et c'est le kernel qui me demande le mot de passe.

        Le secure boot est désactivé.

        Je cherche le moyen de demander au kernel d'utiliser un agencement français. Et je crois que c'est pas gagné.

        Btw, ce genre de bug est TRÈS saoulant, puisqu'il me retire l'accès à mon système, en une mise à jour du noyau dans "stable", donc censée être exempte de bugs bloquants comme celui-ci.

        Quant à reprendre l'ancien noyau, ça ne peut être qu'une solution temporaire, puisque je n'ai aucune envie de conserver un kernel non mis à jour.

        • [^] # Re: Version simple

          Posté par  . Évalué à 3. Dernière modification le 23 janvier 2016 à 01:42.

          Et c'est le kernel qui me demande le mot de passe.

          Le kernel ne demande jamais rien, il n'a pas d'interface utilisateur. C'est l'initramfs qui lance cryptsetup. (voir mon premier post)

  • # Recherche alternative

    Posté par  . Évalué à 2.

    Salut,

    Comme il me semble avoir déjà lu des posts similaires par ici, donc j'ai fait une petite recherche en limitant à linuxfr pour éviter de prendre tout l'internet en compte. Est-ce que ce post peut-il t'aider à résoudre ton problème ?

    Matricule 23415

    • [^] # Re: Recherche alternative

      Posté par  . Évalué à 1.

      Effectivement, ça a fonctionné, merci ! D'ailleurs, si quelqu'un retombe sur ce post, pas besoin d'installer console-data. Les autres commandes ont suffi pour moi.

      • [^] # Re: Recherche alternative

        Posté par  . Évalué à 2. Dernière modification le 23 janvier 2016 à 19:11.

        Salut,

        Ok, super si ma mémoire a fonctionné.

        D'ailleurs, si quelqu'un retombe sur ce post

        En marquant celui-ci [RÉSOLU], on pourra retomber plus vite dessus. Et le précédent ;)

        Matricule 23415

  • # Pas fini

    Posté par  . Évalué à 1. Dernière modification le 23 janvier 2016 à 21:20.

    Bon, finalement, la manip n'a réglé le problème que sur le noyau 4.3 backporté. Ce qui ne me gênerait pas si celui-ci supportait ma Wifi, mais le firmware adapté est introuvable.

    Donc je me retrouve obligé d'utiliser un noyau 3.16 pour que mon laptop fonctionne correctement, or la disposition du clavier y est toujours mauvaise. J'ai essayé de taper mon mot de passe en "traduisant" en QWERTY, mais même ça ne fonctionne plus.

    J'ai fait un update-initramfs -k all -u mais ça ne suffit pas non plus.

    D'autres idées ?

    • [^] # Re: Pas fini

      Posté par  . Évalué à 0.

      Salut,

      finalement, la manip n'a réglé le problème que sur le noyau 4.3 backporté

      C'était pas un peu ce que tu voulais à la base ?

      Ce qui ne me gênerait pas si celui-ci supportait ma Wifi, mais le firmware adapté est introuvable.

      Perso, je remarquerait le sujet ici comme résolu et je referais un post spécifique pour le wifi, histoire qu'on s'y retrouve. Je dis ça, je dis rien….

      Matricule 23415

      • [^] # Re: Pas fini

        Posté par  . Évalué à 1.

        Je voulais régler totalement le problème. Ici il ne l'est pas, puisqu'il m'empêche d'utiliser le noyau "normal" de Debian.

        J'ai installé le noyau backporté pour voir si ça changeait quelque chose. J'aimerais revenir à l'ancien noyau, qui est totalement supporté et qui m'évitera plusieurs problèmes avec les modules, comme celui d'iwlwifi.

    • [^] # Re: Pas fini

      Posté par  . Évalué à 3.

      Donc je me retrouve obligé d'utiliser un noyau 3.16 pour que mon laptop fonctionne correctement, or la disposition du clavier y est toujours mauvaise. J'ai essayé de taper mon mot de passe en "traduisant" en QWERTY, mais même ça ne fonctionne plus.

      Tu est sûr que tu a un problème de QWERTY ?

      Genre après avoir tenté d'entrer ton mot de passe tu tombe dans un shell de secours et là, le clavier et en QWERTY ?
      Parce-que bon, quand on tape le mot de passe pour LUKS c'est à l'aveugle normalement.

      Le problème peut aussi venir de ta disposition fr, certaines dispositions ont des lettres mortes et d'autres non, ce qui peut modifier la façon de taper si ton mot de passe contiens des ^ ou 'ê' par exemple.

      • [^] # Re: Pas fini

        Posté par  . Évalué à 2.

        Précisément, quand j'arrive dans le prompt de mot de passe, je l'entre "à l'aveugle" et LUKS le refuse (Bad password). Puis j'ai de nouveau le prompt. En boucle infinie, jusqu'à ce que je fasse un hard reboot.

        Je suis sûr qu'il est passé en QWERTY, parce qu'en ajoutant un mot de passe moins compliqué (ASCII only), et en le tapant "à l'AZERTY" (c'est à dire que je tape "Q" à la place de "A", "," à la place de "M"…), il est accepté. Mais c'est un contournement assez ennuyeux du problème, parce que mon nouveau mot de passe est moins sécurisé, je dois m'habituer à le taper en QWERTY, et je m'étais habitué à l'ancien et je le tapais presque machinalement (bon j'avoue, ça c'est de la flemme).

        Enfin, je peux très bien me mettre à entrer des mots de passe en QWERTY, mais je m'acharne parce que je trouve ça vraiment ridicule qu'une Debian Stable soit capable de bloquer l'accès au système du jour au lendemain à cause d'une bête mise à jour du noyau. Debian ne m'avait pas habitué à ça.

        La solution la plus utile serait peut-être de signaler le bug à Debian pour que ça n'arrive plus, au lieu d'essayer de le contourner. Sur quel paquet devrais-je le faire ?

        • [^] # Re: Pas fini

          Posté par  . Évalué à 2.

          C'est le paquet initramfs-tools qui est concerné.

          Perso j'arrive pas à reproduire avec initramfs-tools version 0.120, mon /etc/default/keyboard

          XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="latin9"
XKBOPTIONS="compose:menu"

BACKSPACE="guess"

          • [^] # Re: Pas fini

            Posté par  . Évalué à 1.

            Le problème, c'est que le bug survient après une mise à jour du paquet linux-image-3.16.0-4-amd64.

            Ça m'a l'air d'être un truc super spécifique, peut-être dépendant du matériel (je vois pas comment mais pourquoi pas), vu que je l'ai vu deux fois (avec un formatage/réinstall entre les deux) sur mon laptop.

            Du coup je me demande comment ça va bien pouvoir être corrigé si personne ne peut le reproduire. Je vais peut-être vivre avec, vu qu'une fois le bug corrigé avec update-initramfs, il n'a pas l'air de réapparaître.

            D'ailleurs, j'ai fait un autre update-initramfs, et le clavier est de nouveau en AZERTY avec le kernel 3.16.

            En tout cas merci à ceux qui m'ont aidé. Faudra peut-être attendre Debian 9 pour qu'il soit corrigé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.