====== 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''.

<note warning>
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.
</note>

===== 0. Pré-requis et sauvegardes =====

<code>
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
</code>

Noter l'**UUID de la partition LUKS** (type ''crypto_LUKS'') et le **nom du mapper** :
<code>
lsblk -f          # UUID de la partition crypto_LUKS, ex. 4f5ce050-…
ls /dev/mapper/   # nom actuel, ex. luks-4f5ce050-…
</code>
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.

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

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

<note>
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.
</note>

===== 2. HOOKS : pile systemd =====

Dans ''/etc/mkinitcpio.conf'', remplacer la ligne ''HOOKS'' :
<code>
HOOKS=(base systemd autodetect microcode kms modconf keyboard sd-vconsole block plymouth sd-encrypt filesystems)
</code>

Correspondances avec la pile busybox :
  * ''udev'' → ''systemd''
  * ''keymap consolefont'' → ''sd-vconsole'' (lit ''vconsole.conf'' : keymap + police)
  * ''encrypt'' → ''sd-encrypt''
  * ''resume'' supprimé (hibernation gérée via ''resume='' de la cmdline)
  * ''keyboard'' conservé, **avant** ''sd-vconsole''

===== 3. Régénérer =====

<code>
sudo mkinitcpio -P
</code>
Doit finir par ''Initcpio image generation successful'' pour chaque noyau, sans ''ERROR''.

===== 4. VÉRIFIER l'image avant de rebooter =====

<code>
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
</code>
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) =====

<code>
bootctl list
</code>

Deux familles d'entrées peuvent coexister :
  * **Statique** (ex. ''linux-cachyos.conf'') : ''initrd /boot/initramfs-linux-cachyos.img'' → régénérée par ''mkinitcpio -P'' ✓
  * **Auto-générée kernel-install** : ''id'' préfixé par le //machine-id//, ''initrd /boot/<machine-id>/<version>/initrd'' → **PAS régénérée par ''mkinitcpio -P''** → initrd **périmé** avec l'ancienne pile ✗

<note important>
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).
</note>

===== 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 ====

  - Allumer le PC, **maintenir Espace** dès l'écran du fabricant → menu systemd-boot.
  - Surligner l'entrée, touche ''e'' → édition de la ligne ''options''.
  - Retirer ''quiet splash'' (pour voir les messages), démarrer.
  - Si blocage « start job … /dev/disk/by-uuid/<UUID> » : attendre ~1 min 30 → shell d'urgence. Déverrouiller à la main :
<code>
cryptsetup open /dev/disk/by-uuid/<UUID_LUKS> <NOM_MAPPER>
systemctl default
</code>
  - 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.) ====

<code>
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
</code>

Chroot — avec ''arch-chroot /mnt'' si dispo, sinon (live Debian…) :
<code>
sudo mount -t proc proc /mnt/proc
sudo mount --rbind /sys /mnt/sys
sudo mount --rbind /dev /mnt/dev
sudo chroot /mnt
</code>

Puis rejouer les étapes 1→4. Sortie :
<code>
exit
sudo umount -R /mnt      # si « target is busy » : umount -l -R /mnt
reboot
</code>

==== 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) =====

  * Éditer la cmdline **sans** vérifier quelle entrée/initrd démarre réellement (→ étape 5).
  * Rebooter **sans** vérifier le contenu de l'image (→ étape 4).
  * Se fier au seul ''rd.luks.name='' en cmdline au lieu de ''crypttab.initramfs''.
  * Confondre l'UUID **LUKS** (partition ''crypto_LUKS'') et l'UUID du **système de fichiers** (''root=UUID=…'') : le « start job » qui bloque affiche souvent le second alors que le problème est sur le premier.
  * ''root=/dev/mapper/…'' n'est PAS requis : ''root=UUID=<fs>'' fonctionne, le fs est trouvé une fois le LUKS ouvert.