Cours Ubuntu 26.04 / Récupérer après une panne de démarrage, de noyau ou de réseau

Pour récupérer Ubuntu après une panne, commencez par la console, identifiez l’étape réellement atteinte et conservez les erreurs avant de modifier un réglage. Une connexion SSH impossible ne prouve pas un échec de démarrage ; séparez la machine virtuelle, le noyau, les montages, le réseau et le service concerné.

Situer la panne et préserver les éléments utiles

Consignez l’heure, le dernier fonctionnement connu, le changement précédent et le message complet. Préservez les sauvegardes, les clés de déchiffrement et, si possible, une copie cohérente de l’état avant réparation. Ne mettez pas de mots de passe ou de clés privées dans le compte rendu.

Les méthodes de diagnostic par les journaux Linux et de reproduction contrôlée d’une panne servent à tester une hypothèse précise. Ne provoquez pas une perte de disque ou de réseau en production pour apprendre à la corriger.

Recueillir l’état lorsque la connexion locale fonctionne

cat /etc/os-release
uname -r
systemctl --failed --no-pager
df -h
df -i
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

Ces observations ne reconfigurent pas les disques ou services. Comparez l’espace, les inodes, les montages et les erreurs à l’état normal. Une ligne de journal peut être une conséquence ; cherchez aussi les événements précédents et le service qui a échoué.

Si des journaux antérieurs existent, sudo journalctl -b -1 -p err --no-pager examine le démarrage précédent. Leur absence peut venir de la politique de conservation, pas d’une absence d’incident. Le manuel journalctl de systemd 259 définit ces filtres. Pour obtenir le contexte, élargissez la période et consultez les événements par unité et leur conservation.

En cas de disque plein, identifiez ce qui occupe la place et préservez les traces utiles avant un nettoyage ciblé. Effacer tous les journaux peut supprimer la seule preuve disponible sans corriger le processus qui remplit le disque.

Pratiquer une panne de service limitée sur un clone isolé

Cet exercice crée une unité oneshot indépendante, sans activation au démarrage, sans retrait de données et sans changement réseau. Il vérifie une réussite, introduit un ExecStart qui échoue, puis restaure le comportement initial. Il ne reproduit pas une panne de noyau ou de chargeur de démarrage.

Depuis la console d’une VM de test, assurez-vous que ubuntu-recovery-lab.service n’existe dans aucun chemin d’unité ou alias et qu’aucun fragment ne porte ce nom. Consultez systemctl cat ubuntu-recovery-lab.service et systemctl list-unit-files ; leur échec éventuel doit bien correspondre à une absence, pas à un gestionnaire indisponible. Puis exécutez ce bloc complet :

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop" || sudo test -L "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze --recursive-errors=yes verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo mkdir -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze --recursive-errors=yes verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

La première exécution doit donner Result=success et ExecMainStatus=0 ; la seconde Result=exit-code et ExecMainStatus=1. Une commande start non nulle pour une autre raison n’est pas la preuve de l’échec attendu : vérifiez les deux propriétés, la commande chargée et les journaux. Le type oneshot de systemd peut redevenir inactive après une réussite ; inactive ne signifie donc pas nécessairement failed.

Le fichier de surcharge vide d’abord la liste ExecStart, puis définit /usr/bin/false. --recursive-errors=yes rend les avertissements détectés par systemd-analyze verify bloquants pour le script. Relisez quand même leur contenu ; une validation statique ne vérifie pas l’exécution applicative.

Pour restaurer, confirmez que le fragment est bien celui créé ici et qu’il n’a pas été modifié depuis. Retirez uniquement ce fichier :

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

Vérifiez le retour à success et 0. reset-failed efface l’état d’échec mémorisé ; il ne répare pas la cause à lui seul. Pour terminer le laboratoire, contrôlez que l’unité est inactive et appartient bien à cet exercice, puis retirez seulement son fichier et son répertoire de fragments devenu vide, et rechargez le gestionnaire. Le cours des drop-ins et relectures de service explique la distinction entre fichier sur disque et configuration chargée.

Essayer un noyau précédent lorsque GRUB est disponible

Si la panne suit une mise à jour et qu’un noyau antérieur est toujours installé, ouvrez le menu GRUB depuis la console, choisissez Advanced options for Ubuntu puis l’entrée normale d’un noyau précédent. Ne choisissez pas au hasard un disque d’installation et ne supprimez pas le noyau actif.

Sur de nombreuses configurations, Maj pendant le démarrage BIOS ou Échap en UEFI fait apparaître GRUB ; l’hyperviseur et le démarrage rapide peuvent modifier le moment utile. La page Recovery mode du Wiki Ubuntu décrit ces menus. Vérifiez les indications propres à votre VM ou matériel. Un volume chiffré doit encore être déverrouillé avec le moyen prévu.

Si l’ancien noyau démarre, relevez uname -r, les journaux noyau avec journalctl -k -b et l’historique de mise à jour. Si vous utilisez des modules DKMS, vérifiez leur état avec l’outil installé. Un démarrage réussi avec l’ancien noyau réduit le champ de recherche, sans démontrer à lui seul que le nouveau noyau est l’unique cause.

Conservez un noyau fonctionnel et les éléments de diagnostic. Appliquez ensuite une correction correspondant au pilote, au montage ou au paquet réellement en cause, puis vérifiez le démarrage normal. Une réinstallation générique de GRUB ne convient pas à toutes les architectures, dispositions de disque ou configurations de chiffrement.

Identifier le système d’initramfs avant toute reconstruction

L’initramfs est un système de fichiers initial chargé en mémoire pour préparer l’accès au véritable système racine. Ubuntu 26.04 utilise Dracut par défaut, tandis qu’initramfs-tools reste pris en charge ; cette évolution figure dans les changements destinés aux utilisateurs LTS. Une machine mise à niveau peut conserver une organisation différente de celle d’une installation neuve.

dpkg-query -W dracut dracut-core initramfs-tools
command -v dracut
command -v update-initramfs
ls -lh /boot

Les paquets absents peuvent produire des erreurs de recherche ; lisez-les individuellement. La présence d’un outil ne prouve pas comment l’image utilisée a été construite. Vérifiez le noyau concerné et les paramètres de chiffrement, LVM ou RAID avant de choisir une procédure de génération. Ne lancez pas automatiquement une commande copiée d’un guide pour une autre LTS.

Limiter les écritures depuis un mode de récupération

Si le menu est disponible, l’entrée marquée recovery mode puis le choix Drop to root shell prompt peuvent fournir un shell de récupération. Celui-ci est déjà root. Vérifiez d’abord l’erreur, l’identification du disque, les montages et la place disponible :

findmnt /
lsblk -f
df -h

Uniquement si la racine est en lecture seule, que le support est sain et qu’une correction de configuration identifiée nécessite l’écriture, examinez cette opération dans ce shell root :

mount -o remount,rw /

L’absence de sudo est volontaire ici, parce que vous travaillez déjà comme root. Une erreur d’entrée-sortie ou un soupçon de corruption demande d’abord de préserver les données et de choisir une procédure adaptée ; ne répétez pas les tentatives d’écriture. Ne lancez pas une réparation de système de fichiers sur un volume monté et n’initialisez pas un disque dont l’identité reste incertaine.

Avant une modification, conservez le fichier actuel et comparez la sauvegarde correspondant à la période saine. Corrigez un élément identifié, validez-le avec l’outil du composant, puis testez son effet. Ne montez pas aveuglément tous les volumes pour satisfaire une commande copiée.

Retrouver le réseau après un changement de configuration

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

Depuis la console, identifiez l’interface, les adresses, la route, le résolveur et le moteur qui gère effectivement la connexion. La sortie Netplan décrit une configuration fusionnée sur disque, pas à elle seule l’état réseau actif. Consultez la configuration réseau et son retour contrôlé pour comparer ces niveaux.

Comparez le dernier fichier modifié à sa sauvegarde et cherchez un générateur tel que cloud-init. Ajouter un autre YAML peut fusionner des listes au lieu de remplacer le réglage fautif. Préservez aussi l’état actuel avant de restaurer uniquement le fichier concerné et de vérifier la configuration résultante.

sudo netplan generate
sudo netplan try --timeout 120

Exécutez try seulement après réussite de generate et avec la console disponible. generate écrit les fichiers de configuration destinés aux moteurs, même s’il ne les applique pas à lui seul. Les limites documentées de netplan try demandent de vérifier que la restitution a vraiment eu lieu après expiration ou annulation ; ne supposez pas le retour automatique infaillible.

Contrôlez les adresses, routes, résolution et une nouvelle connexion SSH avant d’accepter. Si le réseau fonctionne déjà, examinez séparément les clés et ports SSH puis les règles UFW, sans désactiver globalement les contrôles pour retrouver un accès.

Recourir à un environnement de secours et accepter la récupération

Si l’installation ne permet aucune intervention, préparez un média live ou de secours vérifié, adapté à l’architecture. Identifiez le chiffrement, LVM, RAID et les supports avant d’accéder aux volumes. Lancer l’installateur et sélectionner le disque source comme destination pourrait détruire ce que vous cherchez à récupérer.

Choisissez une procédure de secours correspondant à la disposition réelle, ou restaurez une sauvegarde testée dans un environnement distinct. N’improvisez pas des commandes de repartitionnement, de formatage ou de réinstallation du chargeur pour une configuration inconnue.

Après correction, vérifiez un redémarrage complet, une nouvelle connexion d’administration, les montages, le service et une lecture puis écriture applicative adaptée. Examinez les nouveaux journaux et la reprise des sauvegardes. Consignez l’hypothèse, le changement, son effet et les points encore ouverts : retrouver une première réponse n’est pas encore prouver un fonctionnement durable.