16

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
Improve this question
1
  • Perhaps this needs to be changed to remove the testing from the heading, as it's "confirmed" on Jessie/stable, etc. all since SystemD ;( Commented Sep 18, 2017 at 8:15

5 Answers 5

Reset to default
21

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.

Improve this answer
4
  • 4
    Correct. The plymouth error caught my eye and I overlooked to actual cause. Commented Feb 10, 2015 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 Commented Sep 18, 2017 at 8:12
  • 1
    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. Commented Sep 26, 2018 at 21:17
  • nofail solved the issue for me Commented Apr 7, 2020 at 11:04
12

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.

Improve this answer
1
  • YES!!!!! see my comment in other answer Commented Sep 18, 2017 at 8:14
3

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.

Improve this answer
0
2

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

Improve this answer
0

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)

UPDATE:

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?

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.