Échec à l'étape EXEC spawning / bin / plymouth (tests Debian)

16

Après avoir effectué une dist-upgradesur une instance de test Debian (Jessie), je ne peux plus démarrer. Je suis perdu à l'invite de commande:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs

L'erreur suivante apparaît:

root@debian:~# journalctl -xb
debian systemd[222]: Failed at step EXEC spawning /bin/plymouth: No such file or directory

Étonnamment, Google n'aide pas et le petit fil que je vois est pour Arch (même si j'ajoute + debian dans ma recherche) et n'a pas de sens pour moi.

Un pointeur sur la façon de s'en remettre?

# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x84_64 GNU/Linux

debian upgrade plymouth

— youri
source

Peut-être que cela doit être changé pour supprimer le test de l'en-tête, car il est "confirmé" sur Jessie / stable, etc. depuis SystemD; (

— Hvisage

20

J'ai également eu cette erreur précise aujourd'hui à la suite d'une mise à niveau de Debian Wheezy vers Jessie.

Le système n'a pas pu redémarrer malgré aucune erreur de "apt-get dist-upgrade". La sortie d'erreur finale via "journalctl -xb" (ou "-xd") était associée à "plymouth" (une application dont je n'avais jamais entendu parler). Mais il s'avère que l'échec du redémarrage n'a rien à voir avec plymouth, mais plutôt une anomalie mineure sous une entrée auxiliaire sous / etc / fstab: changez "auto" en "noauto" pour un périphérique cdrom (rien à voir avec NFS), puis systemd permettra le démarrage. Il s'agit d'une ligne fstab qui fonctionnait sous Wheezy et échoue silencieusement pour permettre un redémarrage sous Jessie.

Il n'y a eu aucune erreur via journalctl associée à fstab. Ce sont les recherches sur le Web qui m'ont mené à cette obscure solution.

— Theophrastus
source

4

Correct. L'erreur de plymouth a attiré mon attention et j'ai ignoré la cause réelle.

— youri

Oui, dans mon cas , il déjà était noauto, mais un système de fichiers qui n'était pas « là » parce que du disque supplémentaire ajouté ... <ajoutant-français-choix-mots> systemd qui est absolument juste dû à aspirer le montage systèmes de fichiers ... il devrait en fait s'agir d'un rapport de bogue contre systemd ... mais connaissant LP des expériences précédentes sur le montage de systèmes de fichiers, il sera ignoré; (tout le meilleur pour résoudre les problèmes liés à systemd à l'avenir

— Hvisage

Au lieu de commenter la ligne dans fstab, ajoutez une nofailoption pour tous les systèmes de fichiers non essentiels. Cette option indique à systemd d'ignorer les erreurs lors du montage et de poursuivre le processus de démarrage normal.

— Marki555

11

En combinant les réponses précédentes, ce problème semble être dû à des entrées non valides dans / etc / fstab.

Dans mon cas, je cours à l'intérieur de virtualbox et c'était un dossier partagé que j'avais configuré pour monter automatiquement au démarrage qui était le problème. Dans les deux autres réponses, ce sont les paramètres de périphérique NFS ou CD-ROM qui ont posé problème.

Je suggérerais que pour résoudre les problèmes, il suffit de commenter toutes les lignes non essentielles dans / etc / fstab, puis de les ajouter à nouveau jusqu'à ce que vous reproduisiez le problème.

La ligne problématique peut alors être diagnostiquée et corrigée. Il est possible pendant la mise à niveau dist que des éléments tels que les dossiers partagés Vbox, les partages réseau ou d'autres systèmes de fichiers spécialisés n'aient pas été mis à niveau correctement.

— Chris Noldus
source

OUI!!!!! voir mon commentaire dans une autre réponse

— Hvisage

3

J'ai eu l'erreur exacte aujourd'hui.

J'ai installé plymouth mais cela n'a pas changé le résultat.

Cela a été causé par une entrée nfs incorrecte dans / etc / fstab. Après avoir supprimé cette entrée, l'erreur a disparu. Je suppose que ce comportement horrible est dû au stupide systemd.

— Can Kavaklıoğlu
source

2

Je confirme que c'est un problème dans fstab. Si vous allez dans fstab et supprimez la dernière ligne que vous avez créée, tout est comme avant et le système démarre. J'ai un problème de montage automatique dans le partage dans VirtualBox 5 / debian 8. Aucun problème dans Virtualbox 4 / debian 7

— reylon
source

0

Je vois que c'est un fil assez ancien à ce stade ... mais j'ai également rencontré ce problème aujourd'hui.

J'ai dû commenter cette ligne /etc/fstabpour empêcher le système de démarrer en «mode d'urgence»:

#UUID=0x0000x0-0x00-0000-xx00-0000xxx00000 /boot           ext2    defaults        0       2
/dev/mapper/Ubuntu16043LTSVM--vg-swap_1 none            swap    sw              0       0

* (UUID est intentionnellement obscurci)

MISE À JOUR:

La ligne UUID dans /etc/fstab semble être à l'origine de ce problème. Impair. Après avoir lu plus sur ce problème sur ce fil je n'étais pas encore plus proche d'une réponse définitive sur la cause première, mais au moins le SWAP est configuré maintenant.

Quelqu'un a-t-il pu résoudre complètement ce problème? ou trouver la cause profonde?

— kanidrive
source