Sujet : boot
-
Liste de contrôle d'accès de secours avant toute modification à distance de la configuration de démarrage
Avant de modifier ce qui conditionne le démarrage d'un système distant (entrée par défaut du chargeur d'amorçage, paramètre du noyau, entrée fstab, unité dépendante du réseau ajoutée à une cible de démarrage), vérifiez qu'une seconde voie d'accès existe toujours, que l'accès console fonctionne réellement dès maintenant, qu'un état sain peut être restauré et qu'un retour arrière est écrit à l'avance plutôt qu'improvisé après coup.
-
Administration de GRUB 2 : /etc/default/grub, grub-mkconfig, grubby et entrée par défaut
GRUB 2 se configure de façon indirecte : les réglages résident dans /etc/default/grub et sont compilés dans grub.cfg par grub-mkconfig (appelé via update-grub sous Debian/Ubuntu), tandis que les systèmes de la famille RHEL utilisant les entrées Boot Loader Specification se gèrent généralement avec grubby plutôt que par édition manuelle de grub.cfg.
-
La chaîne de démarrage Linux pour le dépannage : firmware, chargeur d'amorçage, noyau, initramfs et systemd
Un démarrage Linux traverse le firmware, un chargeur d'amorçage, le noyau, un initramfs puis le gestionnaire système, chaque étape passant la main à la suivante. Savoir ce que fait chaque étape et où elle journalise permet de circonscrire un échec de démarrage à une seule étape avant de modifier quoi que ce soit.
-
rescue.target et emergency.target de systemd : y accéder et revenir à un fonctionnement normal
rescue.target démarre le système de base et un shell mono-utilisateur ; emergency.target ignore presque tout et lance un shell sur la console, le système de fichiers racine pouvant encore être en lecture seule. On accède aux deux via le paramètre noyau systemd.unit=, et dans les deux cas il faut ensuite revenir explicitement à default.target.
-
Modifier /etc/fstab en toute sécurité : UUID, nofail, options x-systemd et findmnt --verify
Une ligne erronée dans /etc/fstab peut faire basculer le système dans un shell d'urgence au démarrage suivant. Cette méthode recourt à UUID= plutôt qu'aux noms de périphériques, à nofail et x-systemd.device-timeout= pour les montages facultatifs, puis à findmnt --verify et mount -a pour tester le fichier avant de redémarrer.
-
Reconstruire un initramfs : dracut -f ou update-initramfs -u, et vérifier le résultat
Un initramfs qui n'embarque pas le pilote ou la configuration nécessaires pour trouver et déverrouiller le système de fichiers racine laisse le démarrage bloqué dans un shell précoce. La reconstruction dépend de la distribution (dracut -f sur RHEL/Fedora/SUSE, update-initramfs -u sur Debian/Ubuntu) et doit être vérifiée, avec un noyau de secours conservé, avant de s'y fier.
-
Gérer les services AIX avec le System Resource Controller : lssrc, startsrc/stopsrc et rc.tcpip
AIX gère les démons de longue durée via le System Resource Controller (SRC), un modèle de sous-systèmes et de groupes configuré dans la classe d'objets SRCsubsys de l'ODM, et non via des unités systemd. lssrc, startsrc et stopsrc le pilotent de façon interactive, tandis que /etc/inittab et des scripts comme rc.tcpip déterminent ce qui démarre automatiquement au boot.
-
Dépannage du démarrage de Windows : WinRE, reagentc et le magasin BCD
L'environnement de récupération Windows (WinRE) fournit la réparation du démarrage et une invite de commandes lorsque Windows ne démarre plus ; reagentc indique et contrôle si WinRE est actif, et bcdedit lit et modifie le magasin BCD (Boot Configuration Data), qui détermine ce qui démarre et comment. Sauvegardez-le avec bcdedit /export avant toute modification.
Lisible par machine : JSON