When booting up Ubuntu 16.04, I'm getting this:

Press enter for maintenance( or type Control-D to continue)

and when pressing enter, I get this error:

sulogin cannot read /dev/tty1 permission denied

1 Answer 1


Make sure your /etc/fstab is all correct and reboot. I would recommend commenting out all lines except the essential ones (by putting # at the beginning of the line) and trying to reboot. If it works, try uncommenting the lines one by one and rebooting between each try to see which lines is the problem.

  • Thanks. This was a good hint. In my case, it was a mount entry in fstab that referred to an external HDD. It appears that if that drive was in power-save mode while the computer rebooted it did not connect (over USB connection) and this caused the boot process to fail. My solution was to add the option noauto to the respective entry in fstab (this required, of course, taking care of mounting the external drive manually as it was not mounted automatically anymore - but at least it did not prevent the machine from booting).
    – ElazarR
    Commented Oct 30, 2017 at 7:54
  • This answer also helps in the context of the following question from the Odroid platform forum: forum.odroid.com/viewtopic.php?f=99&t=25892
    – ElazarR
    Commented Oct 30, 2017 at 11:22
  • 2
    How would one edit /etc/fstab if they cannot get past the password prompt at boot? Commented May 17, 2018 at 0:36
  • +1 Also encountered a similar problem today after rebooting a server it reported invalid checksum recovering block 0 in log and EXT4-fs error loading journal after googling it looked as if it had to do with corrupt file system. However this wasn't the real reason I had issue. Because right after pressing Enter it would display the real issue: sulogin cannot read /dev/tty1 permission denied. in my case there was a line in the /etc/fstab file that caused this. This answer saved me :) Commented Jun 24, 2020 at 19:08
  • For me I had to enter maintenance mode and run fsck to fix the non-root file system disk, then after a reboot everything worked again. Before I figured that out, commenting out the fs in /etc/fstab helped to confirm it was that disk causing issues. Commented Sep 23, 2020 at 11:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .