99

My computer booted to a black screen with this error message.

Welcome to emergency mode! After logging in,type "journalctl -xb" to view   
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to   
try again to boot into default mode.

journalctl -xb snippet (what I think is wrong):

-- Unit systemd-fsckd.service has begun starting up.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1 contains a file system with errors, check forced.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1: Inodes that were part of a corrupted orphan linked list found.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: (i.e., without -a or -p options)
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: fsck failed with error code 4.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: Running request emergency.target/start/replace
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: systemd-fsck-root.service: main process exited, code=exited, status=1/FAILURE
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Failed to start File System Check on Root Device.
-- Subject: Unit systemd-fsck-root.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-fsck-root.service has failed.
-- 
-- The result is failed.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Unit systemd-fsck-root.service entered failed state.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: systemd-fsck-root.service failed.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Starting Remount Root and Kernel File Systems...
-- Subject: Unit systemd-remount-fs.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

I ignored other errors like: ACPI PCC probe failed, nvidia not proprietary, etc.

I can access my PC by pressing Ctrl+D , but it is annoying.

karel
  • 122,292
  • 133
  • 301
  • 332
Kim André
  • 1,195

17 Answers17

65

You could run fsck from Ubuntu Live.

  1. Switch on your computer. Boot into a Ubuntu Live DVD/USB (try it without installing).
  2. After it loads, open a terminal by pressing Ctrl+Alt+T

  3. In the terminal, run:

    sudo -i
fdisk -l

    fdisk will inform you what your partition / (root) is called. In this question it is /dev/sdb1.

    Then you should continue by running:

    umount /dev/sdb1
fsck -y /dev/sdb1
poweroff

    If the umount command complains that sdb1 is "not mounted", that is not a problem. We wanted it to be "not mounted" :).

  4. Remove the DVD/USB. Switch your computer on again, to boot from the SSD.

kdarras
  • 185
kyodake
  • 17,808
52

I don't know if u have solved your problem. What I did is : 

sudo nano /etc/fstab

Then delete what you added there for sdb1 and then run: 

sudo systemctl reboot

It says it's corrupted, so I don't know whats up about that, but I hope this could help someone who can't run their Linux.

Videonauth
  • 33,815
Akuma
  • 521
28

I just had the case with Emergency mode. In my situation I followed an installation tutorial which suggested to edit some of the options for my mount points in /etc/fstab . By removing the extra options, my server rebooted without problems.

Steffen Nielsen
  • 381
19

I am using Windows 10 and Ubuntu 16.X dual boot system.

I was not able to mount one of ntfs the partitions and the error was related to windows shutdown/hibernate. I used sudo ntfsfix /dev/sda3 to fix the issue. I was able to mount ntfs partition sda3 but on restart Ubuntu was starting in emergency mode.
To fix this issue, run the following command in windows

shutdown /s /t 5

This fixes Ubuntu emergency start issue.

Rumesh
  • 1,449
Khushboo Rani
  • 191
18

The answers by Khushboo Rani and Cagan Arslan led me to the permanent solution.

Windows 10 has a feature called fast boot enabled by default which, when the user shuts down normally using the "shut down" button or the power button on the computer, will actually save the running kernel and some other system stuff to the hard drive similar to hibernation after logging off. It also causes Windows to "lock" the partition in some way while doing this to prevent corruption of the data, accidental or malicious. This means Ubuntu cannot mount the Windows partition during startup.

In my case, I have entries for the Windows partition in /etc/fstab, so this made Ubuntu unbootable.

The solution is to boot into Windows, disable "fast boot", and then shut down normally. Now the problem should be solved permanently!

From the link I shared earlier, disable fast boot while in Windows as follows:

  1. Launch the control panel
  2. Go to the "Hardware and Sound" settings
  3. Go to "Power Options"
  4. Click "Choose what the power buttons do"
  5. Click "Change settings that are currently unavailable" and grant UAC access.
  6. Clear the checkbox by the "Turn on fast startup (recommended)" setting
Community
  • 1
Ben
  • 832
7

In my case (Dual Boot Windows 10) i had to properly shut Windows down with the command (on windows):

shutdown /s /t 5

When i restart, Ubuntu loads without problem.

Cagan Arslan
  • 71
4

If this happens in a VirtualBox VM then it may be that it has failed to mount one of the partitions in /etc/fstab - unfortunately it fails with "welcome to emergency mode!" even if it's not a critical partition - for example if you've added a malformed entry to attempt to mount a filesystem using vboxsf then the whole system fails to boot without making it very clear in the boot log that this is the cause of the problem.

Anyway to clear the problem you need to either comment out the offending entry in /etc/fstab or modify it so that mount is happy with it.

Pierz
  • 3,391
3

I've just had exactly the same problem, booting Ubuntu LTS 16.04 from a USB flash drive. Doing sysctl default did not fix it, fsck would flash shortly with scanning progress msg and then same prompt would come up. Here is what worked:

fsck -y /dev/sda1
reboot
Jackie Jim
  • 221
2

Similar to some of the other answers, the trick for me was to comment out an entry in /etc/fstab for my optional LVM partition. I don't know why it started to complain a few days ago that Ubuntu 17.10 could no longer find the LVM partition, nor why this was causing the system to boot into "emergency" mode.

Once the entry was commented out in /etc/fstab, I rebooted successfully to my desktop. Looking at some tutorials, I noticed I was missing some LVM commands, so I ran sudo apt-get install lvm2 which seems to have fixed the problem.

If like me you think your LVM partition is the cause of the issue, the full set of commands I ran was:

sudo lvmdiskscan
sudo apt-get install lvm2
sudo lvmdiskscan
sudo lvdisplay
sudo vi /etc/fstab
sudo vgchange -a y
sudo mount -a

Not sure if all these are necessary -- I suspect that apt-get install lvm2 was key to getting my system to boot again.

Stéphane
  • 2,536
1

So there are many good answers here - just to add to the info, my issue was a mistake in spelling tmpfs as tempfs which is incorrect in a line I added to /etc/fstab to secure a server

user3728501
  • 1,142
0

I just had the same issue and in my case, I had just recreated my grub partition and therefore it had a differente UUID than the last grub partition I had. When I booted ubuntu, the system wouldn't be able to check the UUID. To fix this problem I did:

sudo nano /etc/fstab

Then comment out the line containing the UUID from the partition I had just modified.

then reboot to apply changes.

Gabriel Ziegler
  • 1,546
0

All the above answers did not help me, as I didn't have a recovery file for fstab.
What did the trick was (in emergency mode)

cat /proc/mounts > /etc/fstab
DsCpp
  • 143
0

I also came across same error showing (/dev/xyz) VFS: cant find ext4 filesystem.

I was not even having root user password for login.

So I following following steps to solve it,

  • Boot into a Ubuntu Live DVD/USB (Press F11 to select quick book option)
  • Recover root password using this method Reset root password for Ubuntu 16.04

  • Check file system status using following commands,

    df -h
lsblk --fs --ascii 
lsblk -l;
fdisk -l;

  • Remove umount /dev/xyz volume and fix it using fsck / xfs_repair as per File system type.

umount /dev/sdb1 fsck -y /dev/xyz

  • In my case mount point was missing but fstab was having entry for it. So I created same mount point again and updated fstab entry using following commands.

sudo mkdir -p /mnt/abc sudo mount /dev/xyz /mnt/abc vim /etc/fstab UUID=xxxxxxxxxx-eeee-rrrrr-807a-xxxxxxxxxx /mnt/abc xfs rw,noatime 0 2

  • Then just reboot system.

sudo systemctl reboot

It worked for me.

Hemant Thorat
  • 361
  • 2
  • 4
0

In my case, I added a partition of a usb drive in /etc/fstab. when I booted with the usb drive removed, the error occurrd

all I needed to solve the issue is to remove the line about the usb drive. i know that you have resolved ur issue but this may be helpful for other people :)

Kenivia
  • 267
0

Ahoy!

I had been booting into emergency mode for quite a while. I would hit enter and type exit or ctrl-d, sometimes I had to do this several times but eventually it would usually work. I wanted to figure out what was wrong and boot straight into Ubuntu without emergency mode. Windows 10 came factory installed on my laptop which was booting fine. I removed windows 10 and installed a test copy of Ubuntu on /dev/sda1 and it was not booting into emergency mode. So then I was hopeful it was not a hardware error i.e. just broken. I read the above accepted solution and thought maybe if I ran fsck -y /dev/sda6 it would solve the problem, unfortunately that did not work. Then I read this article

Wrong EFI System Partition GUID?

and ran more /etc/fstab on both Ubuntu partitions. Even though I installed both Ubuntu partitions on the same laptop, there were two different UID values for /boot/efi in fstab.

The old Ubuntu install that was booting into emergency mode had this

UUID=BEAA-DA23  /boot/efi       vfat    defaults      0       1

The new blank Ubuntu test partition had this

/dev/disk/by-uuid/AB34-68EA /boot/efi vfat defaults 0 1

I ran blkid and it tells you the UUID's of the root partition and the swap partition, but not the /boot/efi partition which in hindsight was the one causing the problem. When I removed my windows partition, I had to create a new /boot/efi partition, and the UUID changed when I did this. The new Ubuntu install noticed this and configured correctly. But the old one, the one where I installed all my programs and had all my data, remained unchanged. If you want to find the UUID of your /boot/efi partition without installing a new copy of Ubuntu, you can run ls -l /dev/disk/by-uuid and the UUID of the /boot/efi partition should be there. It is also listed in gparted if you run sudo gparted and double click on the partition. Gparted also told me to install some packages via apt so it could properly read a vfat partition. I did this using apt via

sudo apt install dosfstools mtools

I ran sudo emacs /etc/fstab, on the old Ubuntu partition, commented out the old line like this

#UUID=BEAA-DA23  /boot/efi       vfat    defaults      0       1

And under it put the new /boot/efi information from the Ubuntu test partition.

/dev/disk/by-uuid/AB34-68EA /boot/efi vfat defaults 0 1

And so far that is working. I had a random reboot earlier that doesnt usually happen, but I think that might be something else. When I rebooted it again did not boot into emergency mode and booted straight into Ubuntu. Problem appears solved so far! Hope that explanation can help someone else.

Good Luck!

update:

I am starting to think the UUID is another new partially broken replacement that wasnt as good as what we already had. For the /boot/efi partition, and all your other ones for that matter, I think you can avoid UUID's all together and just use the /dev/sda2 device which is traditionally what has worked and what Linux/Unix has always done. I think

/dev/sda2 /boot/efi vfat defaults 0 1

Will work just fine, and you can avoid UUID's altogether unless they have some other use I am not aware of. Google says it is good for if you are adding storage, but when the UUID changes, you have to manually fix fstab the same as when the /dev device changes. And when I add storage I normally leave the boot partition in place.

It seems they are creating many different aliases to reference the same thing again. Simply using the /dev name is how it has always been done, and is IMO better than some long meaningless random number that in some hidden way points to the /dev device.

user3408541
  • 141
0

I had same problem , after running command fsck it was recovering but after some time my computer was going in emergency mode again so i removed whole data from my Hard disk and installed new OS. It solved my problem. I think so problem was with Ubuntu 15.0 vivid version so i installed 14.0 version. Still yet there is no problem.

Mohit Satish Pawar
  • 41
0

I had the same issue. Commented manually added ntfs partitions from /etc/fstab System started normally. Used ntfsfix command to fix the journaling problem caused to those ntfs partitions Eg: Sudo ntfsfix /Dev/ntfs partition Mounted again in /etc/fstab Reboot

Binoy
  • 1