Une VM Debian refuse de démarrer, part en emergency mode, et le shell de secours vous claque la porte au nez parce que root est verrouillé. Le passage par init=/bin/bash dans GRUB contourne le blocage et permet de réparer le système de fichiers proprement.
Le symptôme
Observé sur une VM Debian 12 sous AHV, LVM, avec /var sur un LV séparé. À la console :
root00: clean
usr00: clean
[FAILED] systemd-fsck@dev-mapper-...lv_var00Le fsck de /var échoue, puis une cascade de [DEPEND] emporte var.mount, local-fs.target et les services, et la VM finit en emergency mode. C’est le comportement documenté : d’après systemd.special(7), emergency.target est utilisé quand la vérification d’un système de fichiers requis échoue et que le démarrage ne peut pas continuer.
Puis vient le message qui bloque :
Cannot open access to console, the root account is locked.Root est verrouillé : aucun mot de passe défini (! ou * dans /etc/shadow, ce que sulogin(8) appelle un compte verrouillé), choix courant sur un parc administré par clés SSH. Le shell d’urgence exige le mot de passe root : il est inaccessible. Ce message est celui cité dans l’issue systemd #11596, toujours ouverte, qui discute justement du cas d’un root verrouillé en rescue et emergency.
La réparation
Redémarrer la VM, appuyer sur e dans le menu GRUB, puis sur la ligne qui commence par linux : retirer quiet et ajouter init=/bin/bash en fin de ligne. Démarrer avec Ctrl+X.
La doc du noyau définit init= simplement : lancer le binaire indiqué à la place de /sbin/init. Pas de systemd, donc pas de sulogin : on obtient un shell root sans mot de passe, / en lecture seule, /var non monté. C’est exactement l’état qu’il faut pour un fsck.
fsck -fy /dev/mapper/<vg>-<lv_var>Une rafale de messages « orphaned inodes » est normale. Relancer la commande jusqu’à obtenir « clean ». Si le superbloc principal est hors d’usage, passer par un superbloc de secours (32768 est le premier pour un ext4 en blocs de 4 Kio, cas de cette VM) :
fsck -b 32768 -y /dev/mapper/<vg>-<lv_var>Pour sortir, pas de reboot classique : il n’y a pas d’init pour orchestrer l’arrêt.
/usr/sbin/reboot -fAprès le boot
Chercher la cause, sinon la panne reviendra. Deux pistes à vérifier : un LV saturé, ou un arrêt brutal (redémarrage HA par exemple).
df -h /var /var/logLe préventif, et la fausse bonne idée
Le vrai correctif est de définir un mot de passe root utilisable à la console, pour que le mode emergency serve à quelque chose.
La tentation inverse existe : forcer l’ouverture du shell sans mot de passe. La variable SYSTEMD_SULOGIN_FORCE évoquée dans l’issue #11596 fait cela. La page sulogin(8) est claire sur l’option équivalente --force : avec un root verrouillé, plus aucun mot de passe n’est demandé, et l’option ne doit être utilisée que si la console est physiquement protégée. Appliqué à une VM, cela revient à donner un shell root sans mot de passe à quiconque accède à sa console : à éviter.
Ce qu’il faut retenir
- Un fsck requis en échec mène à
emergency.target; avec root verrouillé, le shell d’urgence est inaccessible. init=/bin/bashdans GRUB donne un shell root,/en lecture seule,/vardémonté : l’état idéal pourfsck -fy.- Superbloc HS :
fsck -b 32768 -y. Sortie :/usr/sbin/reboot -f. - Snapshot AHV avant, recherche de cause après (
df -h /var /var/log, arrêt brutal). - Préventif : un mot de passe root console, pas
SYSTEMD_SULOGIN_FORCE.
In English
A fsck fails on /var, the Debian VM drops into emergency mode, and the locked root account blocks the rescue shell. Booting with init=/bin/bash gives a root shell without a password, with / read-only and /var unmounted, so fsck can run. With no init available, the way out is a forced /usr/sbin/reboot -f.
Sources & vérification
Testé sur : Debian 12 sur AHV (LVM, /var sur un LV séparé)
- Kernel parameters kernel.org
- systemd.special(7) man7.org
- sulogin(8) man7.org
- systemd issue 11596 github.com
- Expérience directe de l’auteur, en production (versions ci-dessus)