Table des matières

Clavier FR au prompt LUKS (CachyOS + Plymouth)

Symptôme : au démarrage, l'invite de mot de passe LUKS interprète le clavier en us, alors que /etc/vconsole.conf contient KEYMAP=fr.

Cause : avec la pile initramfs busybox par défaut (udev + keymap + encrypt), Plymouth n'applique pas la keymap chargée dans la console. Solution : basculer sur la pile systemd (systemd + sd-vconsole + sd-encrypt), dont l'invite (systemd-cryptsetup) honore vconsole.conf.

Manip sur le déverrouillage de la racine chiffrée : une erreur rend le système non amorçable (récupérable, mais pénible). Règles d'or, tirées d'un plantage réel :
  • faire les sauvegardes de l'étape 0 ;
  • vérifier le contenu de l'initramfs AVANT de rebooter (étape 4) ;
  • savoir quelle entrée de boot et quel initrd sont réellement démarrés (étape 5 — c'est le piège n°1) ;
  • garder un live USB sous la main et lire la section Récupération avant de commencer.

0. Pré-requis et sauvegardes

cat /etc/vconsole.conf          # doit contenir KEYMAP=fr (XKBLAYOUT=fr conseillé)
sudo cp /etc/mkinitcpio.conf /etc/mkinitcpio.conf.bak
sudo cp -r /boot/loader/entries /boot/loader/entries.bak

Noter l'UUID de la partition LUKS (type crypto_LUKS) et le nom du mapper : 

lsblk -f          # UUID de la partition crypto_LUKS, ex. 4f5ce050-…
ls /dev/mapper/   # nom actuel, ex. luks-4f5ce050-…

Ne pas confondre avec l'UUID du système de fichiers à l'intérieur (celui de root=UUID=…).

1. Déclarer le volume : crypttab.initramfs (méthode principale)

C'est la méthode native et robuste de sd-encrypt : elle fonctionne quelle que soit l'entrée de boot, sans toucher à la cmdline. 

sudo tee /etc/crypttab.initramfs <<'EOF'
<NOM_MAPPER> UUID=<UUID_LUKS> none luks
EOF

Exemple : luks-4f5ce050-… UUID=4f5ce050-… none luks

Alternative cmdline : rd.luks.name=<UUID_LUKS>=<NOM_MAPPER> dans la ligne options de l'entrée démarrée. Fonctionne aussi, mais fragile : il faut l'ajouter dans chaque entrée, et les entrées auto-générées sont réécrites. Préférer crypttab.initramfs. Ne PAS supprimer cryptdevice= existant : il est ignoré par sd-encrypt et permet un retour arrière.

2. HOOKS : pile systemd

Dans /etc/mkinitcpio.conf, remplacer la ligne HOOKS : 

HOOKS=(base systemd autodetect microcode kms modconf keyboard sd-vconsole block plymouth sd-encrypt filesystems)

Correspondances avec la pile busybox :

3. Régénérer

sudo mkinitcpio -P

Doit finir par Initcpio image generation successful pour chaque noyau, sans ERROR.

4. VÉRIFIER l'image avant de rebooter

sudo lsinitcpio /boot/initramfs-linux-cachyos.img | grep -cE 'systemd-cryptsetup'   # attendu : >= 1
sudo lsinitcpio /boot/initramfs-linux-cachyos.img | grep -c  'etc/crypttab'         # attendu : 1
sudo lsinitcpio /boot/initramfs-linux-cachyos.img | grep -c  'etc/vconsole.conf'    # attendu : 1

Un 0 quelque part → ne pas rebooter, corriger d'abord (hook manquant, crypttab absent, vconsole vide).

5. Identifier l'entrée de boot réellement utilisée (PIÈGE N°1)

bootctl list

Deux familles d'entrées peuvent coexister :

C'est LE piège : booter une entrée auto-générée après la bascule → l'initrd périmé + la nouvelle cmdline peuvent se contredire → blocage sur « a start job is running for /dev/disk/by-uuid/… » sans invite de mot de passe.

Après reboot, choisir explicitement l'entrée statique au menu (Espace au démarrage pour l'afficher). Les initrd /boot/<machine-id>/… seront régénérés au prochain upgrade de noyau ; on peut aussi les régénérer de suite avec sudo kernel-install add-all (ou supprimer ces entrées si non désirées).

6. Rebooter et tester

Reboot → entrée statique → invite LUKS → tester un caractère discriminant us/fr (a/q, m/:). Après connexion : cat /proc/cmdline pour confirmer l'entrée démarrée.

Récupération (si blocage au boot)

A. Sans live USB : depuis le menu de boot

  1. Allumer le PC, maintenir Espace dès l'écran du fabricant → menu systemd-boot.
  2. Surligner l'entrée, touche e → édition de la ligne options.
  3. Retirer quiet splash (pour voir les messages), démarrer.
  4. Si blocage « start job … /dev/disk/by-uuid/<UUID> » : attendre ~1 min 30 → shell d'urgence. Déverrouiller à la main :
cryptsetup open /dev/disk/by-uuid/<UUID_LUKS> <NOM_MAPPER>
systemctl default
  1. Pour forcer un shell tôt dans l'initramfs : ajouter rd.systemd.unit=emergency.target à la ligne (rd.break est dracut, inopérant sur mkinitcpio).

B. Avec live USB (CachyOS, Debian, etc.)

sudo cryptsetup open /dev/disk/by-uuid/<UUID_LUKS> cryptroot
sudo mount -o subvol=/@ /dev/mapper/cryptroot /mnt    # btrfs : monter LE SOUS-VOLUME @
ls /mnt                                                # doit montrer etc, usr… (si @ @home → remonter avec subvol=/@)
sudo mount /dev/<partition_EFI> /mnt/boot

Chroot — avec arch-chroot /mnt si dispo, sinon (live Debian…) : 

sudo mount -t proc proc /mnt/proc
sudo mount --rbind /sys /mnt/sys
sudo mount --rbind /dev /mnt/dev
sudo chroot /mnt

Puis rejouer les étapes 1→4. Sortie : 

exit
sudo umount -R /mnt      # si « target is busy » : umount -l -R /mnt
reboot

C. Retour arrière complet

Dans le chroot : restaurer /etc/mkinitcpio.conf.bak et /boot/loader/entries.bak, puis mkinitcpio -P. La pile busybox reprend via le cryptdevice= conservé (prompt en us, mais système amorçable).

Erreurs à ne pas reproduire (retour d'expérience)