After I performed a dist-upgrade on a Debian testing (Jessie) instance, I can no longer boot. I'm marooned at the command prompt:

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

The following error shows up:

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

Surprisingly, Google is not helping and the little thread I see are for Arch (even if I add +debian in my search) and don't make sense to me.

Any pointer on how to recover from this?

# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x84_64 GNU/Linux
  • Perhaps this needs to be changed to remove the testing from the heading, as it's "confirmed" on Jessie/stable, etc. all since SystemD ;( – Hvisage Sep 18 '17 at 8:15

I also had this precise error today as the result of a debian wheezy to jessie upgrade.

The system failed to reboot despite no errors from "apt-get dist-upgrade". The final error output via "journalctl -xb" (or "-xd") was associated with "plymouth" (an application that I'd never heard of). But it turns out failing to reboot had nothing to do with plymouth, but rather a minor anomaly under an ancillary entry under /etc/fstab: change "auto" to "noauto" for a cdrom device (nothing to do with NFS) and then systemd will allow the boot. This is an fstab line which functioned under wheezy and fails silently to allow a reboot under jessie.

There was no error via journalctl associated with fstab. It was lucky web searches that lead me to this obscure solution.

  • 4
    Correct. The plymouth error caught my eye and I overlooked to actual cause. – youri Feb 10 '15 at 10:08
  • Yes, in my case it already Was noauto, but an filesystem that wasn't "there" 'cause of the extra added disk... <adding-French-choice-words> systemd that absolutely just had to suck up the mounting of filesystems... it should actually be a bug report against systemd... but knowing LP from previous experiences about filesystem mounting, it'll be ignored ;( All the best in solving systemd related troubles in future – Hvisage Sep 18 '17 at 8:12
  • Instead of commenting out the line in fstab, add nofail option for all non-essential filesystems. This option tells systemd to ignore errors during mount and to continue normal boot process. – Marki555 Sep 26 '18 at 21:17

Combining the previous answers, this issue does appear to be caused by invalid entries in /etc/fstab.

In my case I am running inside virtualbox and it was a shared folder I had set up to auto mount on boot that was the problem. In the other two answers it was the settigns for NFS or CD-ROM device that was the issue.

I would suggest that to troubleshoot, just comment out all non-essential lines in /etc/fstab and then re-add them one by one until you replicate the problem.

The problematic line can then be diagnosed and fixed. It is possible during the dist upgrade that things like Vbox shared folders, network shares or or other specialized file systems were not upgraded correctly.

  • YES!!!!! see my comment in other answer – Hvisage Sep 18 '17 at 8:14

I had the exact error today.

I installed plymouth but it did not change the result.

It was caused by a wrong nfs entry in /etc/fstab. After deleting that entry the error disappeared. I guess this horrible behaviour is due to the stupid systemd.


I confirm that is a problem in fstab. If you go inside fstab and delete the last line you made all is like before and the system start. I have a automount problem in sharing in VirtualBox 5 / debian 8. No problem in Virtualbox 4 / debian 7


I see this is a rather old thread at this point... but I also experienced this issue today.

I had to comment out this line in /etc/fstab to prevent the system from booting in 'emergency mode':

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

*(UUID is intentionally Obfuscated)


The UUID line in /etc/fstab seems to be at fault for this issue. Odd. After reading more about this issue on this thread I was still no closer to a definitive answer on the root cause, but at least the SWAP is configured now.

Has anyone been able to solve this issue completely? or find the root cause?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.