Démarrer un système de secours ou live et utiliser chroot pour réparer un Linux installé

Objectif

Réparer un système Linux installé (réinstaller un chargeur d'amorçage, corriger un paquet, réinitialiser un mot de passe, modifier une configuration que le système installé ne démarre plus assez loin pour éditer lui-même) à partir d'un support de secours ou live indépendant, en utilisant les binaires du système installé via chroot.

Prérequis

Un support de secours ou live (mode de secours d'un installeur, clé USB live ou image de secours cloud) d'une architecture de processeur compatible ; les droits root sur ce support ; les disques du système installé visibles depuis celui-ci, avec la phrase secrète de chiffrement à portée de main le cas échéant.

Étapes

1. Démarrer le support de secours ou live et identifier la partition racine du système installé : utiliser lsblk -f ou blkid pour faire correspondre les étiquettes et UUID des systèmes de fichiers avec ceux qu'attend le fichier /etc/fstab du système installé.
2. Monter la racine installée dans un répertoire de travail, par exemple avec mount /dev/<root-partition> /mnt (avec Btrfs, indiquer le sous-volume racine, par ex. -o subvol=@ sur Ubuntu ou -o subvol=root sur Fedora). Si /boot ou /boot/efi se trouvent sur des partitions distinctes, les monter dans leurs sous-répertoires sous /mnt avant de poursuivre : le chroot doit les voir aux emplacements qu'attend le système installé.
3. Rendre les systèmes de fichiers virtuels du noyau visibles dans la cible : for d in dev proc sys run; do mount --rbind /$d /mnt/$d; mount --make-rslave /mnt/$d; done. L'option --rbind reprend aussi les sous-montages tels que /dev/pts et, sur un système de secours démarré en UEFI, /sys/firmware/efi/efivars ; un simple --bind de /sys n'inclut pas efivarfs (dans ce cas, le monter avec mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars). L'option --make-rslave évite qu'un démontage récursif ultérieur ne se propage vers le système de secours. Le support de secours doit lui-même avoir été démarré en mode UEFI, faute de quoi il n'existe aucune variable EFI dans laquelle écrire.
4. Entrer dans le chroot : chroot /mnt /bin/bash exécute le shell « with root directory set to » /mnt (chroot(1)), de sorte que les programmes résolvent les chemins et la configuration à partir du système installé.
5. Effectuer la réparation avec les outils du système installé. Chargeur d'amorçage, BIOS/MBR : grub-install /dev/<disk> (disque entier ; grub2-install sur RHEL). UEFI sur Debian/Ubuntu : grub-install --target=x86_64-efi --efi-directory=/boot/efi. UEFI sur la famille RHEL : ne pas exécuter grub2-install (cela remplacerait la chaîne signée de Secure Boot) ; réinstaller plutôt les paquets, par ex. dnf reinstall shim-x64 grub2-efi-x64 (cela exige un accès aux dépôts depuis l'intérieur du chroot). Régénérer ensuite grub.cfg à l'emplacement utilisé par la distribution. Autres réparations : réinstaller un paquet, modifier /etc/fstab, passwd <user> (sur les systèmes SELinux, exécuter ensuite touch /.autorelabel), reconstruire un initramfs (en indiquant explicitement la version du noyau).
6. Quitter le chroot, exécuter sync, puis umount -R /mnt, qui démonte dans le bon ordre les montages liés, /boot/efi, /boot et la racine. Si une cible est signalée comme occupée, identifier le processus responsable (fuser -vm /mnt) plutôt que de forcer le démontage.
7. Redémarrer en retirant le support de secours, puis vérifier que le système démarre à nouveau normalement.

Résultat attendu

Les commandes exécutées dans le chroot se comportent comme si elles tournaient nativement sur le système installé ; après le démontage et le redémarrage, le système installé démarre par lui-même.

Limites et base de vérification

Un chroot partage le noyau du système de secours, et non celui du système installé, et il n'isole ni le réseau, ni les utilisateurs, ni les identifiants de processus : les commandes qui s'y exécutent disposent de tous les privilèges root sur l'hôte. Si la racine installée repose sur LVM, RAID ou LUKS, il faut activer ces couches (vgchange -ay, mdadm --assemble, cryptsetup open) avant la première étape de montage. L'absence d'efivarfs dans le chroot est une cause fréquente d'échec de grub-install sur les systèmes UEFI, car la commande a besoin des variables EFI pour écrire l'entrée de démarrage.