I am doing a clean install of Ubuntu Server 16.04 LTS on a machine with a single internal SSD. After completing the install, the system fails to boot and prints a single line fsck output, with the rest of the screen entirely blank.

enter image description here

This very same server installs Ubuntu Server 14.04.4 LTS just fine, so this is very specific to 16.04 LTS. I've tried installing every which way I can think of in 16 and I get the same results every time: installation completes with no errors, but upon reboot I get a black screen with that one line of fsck output after rebooting :(

I noticed that one big difference between 14 and 16 installs on this server machine (which is unexceptional, it's just a generic Broadwell i5 box with 16GB RAM and Samsung 850 EVO SSD) is that Ubuntu 14 detects and installs the drive as /sda whereas Ubuntu 16 detects and installs the drive as /sdc -- furthermore, Ubuntu 16 detects the USB flash drive with the Ubuntu install as /sda! This strikes me as .. very incorrect.

enter image description here

How can I get the Ubuntu Server 16.04 install to stop treating the USB installation drive as /sda?

Edit: per request, here's the output of fdisk after pressing alt+ near the end of the install

fdisk during install

here's the output of

# mkdir /mnt/ssd
# mount /dev/sdc1 /mnt/ssd
# nano /mnt/ssd/etc/fstab

fstab in nano

When I boot into "rescue mode" from the USB install media (no option to boot in recovery mode is presented to me), I get the following options for "device to use as a root file system"

Assemble RAID array  
Do not use a root file system  

Notice that no /sdc filesystem is detected or shown. However, when I enter console under /sda1 and fdisk -l I do see what I installed as /sdc!

recovery mode fdisk -l

I tried "Reinstall GRUB boot loader" targeting /sda1 and I get an error. I tried it again with /sda as the target, and that seemed to work.

But rebooting, same black screen, single like fsck output unfortunately.

  • 2
    Sda / sdc shouldn't matter, I believe, because most distros have been using UUIDs for a while now. Maybe try to get some more details by looking at the available boot options such as recovery mode: wiki.ubuntu.com/RecoveryMode
    – Shtééf
    Apr 23, 2016 at 7:41
  • Yes going into recovery and reviewing your /etc/fstab is definitely the next step. Then you might need to reinstall grub.
    – chx
    Apr 23, 2016 at 8:18
  • @Shtééf recovery mode shows nothing, in fact, in recovery mode I can't even see the /sdc volume at all. Apr 23, 2016 at 11:01
  • 1
    Can you enable debug mode? wiki.archlinux.org/index.php/boot_debugging
    – Braiam
    Apr 23, 2016 at 17:53
  • 2
    In the grub menu, type e to edit the default entry, and append debug at the end of the line that says quiet. In fact, removing quiet is fine.
    – Braiam
    Apr 24, 2016 at 3:12

5 Answers 5


I noticed the same behavior with 16.04 net install.

If your issue is the same as mine, it actually booted fine it's just showing you tty7.

Try hitting ctrl+alt+F1 that should take you to the terminal with a login prompt.

  • 3
    Wow this is totally it! I pressed ctrl+alt+F1 and I have a booted system. This is so weird! Why is this happening? Apr 25, 2016 at 21:37
  • 4
    @JeffAtwood lightdm/X is started on tty7, so desktop Ubuntu will boot to that. Likely an oversight somewhere with the release.. Needs to be filed as a bug, but I'm not sure where.
    – Seth
    Apr 27, 2016 at 4:25
  • Anyone ever find or file a bug for this? I cannot repro. May 14, 2016 at 22:39
  • 2
    The hell .... I just spend 3hours ghosting & re-ghosting everything trying to search for a UEFI issue.... tty7.... thank you a lot !
    – 131
    May 17, 2016 at 20:50
  • 1
    Can anything be done to prevent the need to press ctrl + alt + F1 every time I want to login? Dec 29, 2017 at 1:04

I had the same problem last night with Ubuntu 15.10. Turned out I knocked out a SATA connector on a (secondary) drive. No actual error is output here, which was quite confusing until I opened up and noticed the connector out of place.

Leads me to think that for you it’s looking for the flash drive using some sort of identifier that in some way has changed between the live USB boot and the boot of the installed system, or you just haven’t tried booting with the drive attached.

Boot a live OS (you should be able to get away with reusing your Ubuntu Server flash drive – hit Alt to get to a command line). Get a list of disks and partitions:

# fdisk -l | less

Obviously it’ll be on sdc, but determine which partition is the ext4 system one.

Mount the partition (assuming sdc2):

# mkdir /mnt/ssd
# mount /dev/sdc2 /mnt/ssd

Now inspect its fstab:

# nano /mnt/ssd/etc/fstab

If this is a UEFI install, you should probably only have lines for the EFI system partition (/boot/efi), the boot partition (/boot), and the system root (/). The setup helpfully annotates the lines it made in the generated fstab, so anything not on /dev/sdc* should be removed (or just comment it out to be safe).

Save that (CtrlX, Y, Enter), and do

# sync
# reboot

to ensure changes are committed to disk and reboot. Disconnect the flash drive and see how it goes.

A few common reasons I’ve seen flash drives appear before the system drive are due to a BIOS setting being used that allows you to fake the drive to another type (floppy drive, hard drive, etc) rather than relying on the drive’s own identification, or because the drive has had the removable bit turned off. Are you using the same drive for the 14.04 installer as you are for 16.04? If you’re certain it’s not on your end then it does sound like an OS bug.

  • yep everything is 100% identical, zero hardware changes. Ubuntu 14 LTS installs fine on this server. Apr 23, 2016 at 10:59
  • ok this is certainly more info, thanks, I have updated the question with the information you requested. I don't see anything wrong in those screenshots? Apr 24, 2016 at 2:28

You are mislead by the sda/sdc issue. Your fstab shows that the machine assigns file systems per UUID, and on top of that, the fsck line shows that grub could start the initrd which did the initial filecheck.

It could be something as simple as wrong graphics setting for the kernel. Basically, you can't see the ttys, and X is not on your server, correct?

Try and add nomodeset to the GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" line in /etc/default/grub, and also add a line GRUB_GFXPAYLOAD_LINUX=keep.

I had two systems with 16.04 showing similar symptoms as you describe, but since they could boot to X, I could fix it in a running system. It was very similar, I saw the fsck line (on tty1) or nothing at all (on tty2-6).

  • apparently it's sending tty7 output to the main display, but it is booting successfully? no idea why, or how to fix. ctrl+alt+f1 lets me switch to the "real" console. Apr 26, 2016 at 5:49
  • 1
    In a normal system, the initialization includes bringing tty1 to the foreground so it gets the display and you see the login prompt, you also see the error and status messages on the display. For your case, only error and status messages, the complete initialization happens only with the Alt-F2 when another tty is started. Try with GRUB_CMDLINE_LINUX_DEFAULT="nomodeset quiet splash" as advised, add the other line as well. This made the initialization finish for me. I got the tty1 login prompt after I did this, on two computers.
    – emk2203
    Apr 26, 2016 at 6:09
  • In this case the easy workaround is OK (I usually SSH into this box anyway), but it is a disturbing bug, I hope it can be fixed in the release. Apr 29, 2016 at 10:27

I just installed Ubuntu Server 16.04.1 LTS and encountered the exact same problem.

This issue is caused by the grub option GRUB_CMLDLINE_LINUX_DEFAULT being set to "quiet splash", just like in the Desktop version of Ubuntu. The splash screen is shown instead of the usual verbose boot text.

Somehow after the boot process is done, the console gets dropped to tty7, which is the non-existent xserver GUI, which results in the abovementioned issue.

Set it back to "text" and after all that verbose boot messages Ubuntu Server will boot into tty1 console.

Edit: As mentioned by @emk2203, this issue is not caused by the bootloader being installed to the wrong drive. The installation actually succeeds to boot, but due to the bug in the grub config the nonexistent tty7 is sent to the main display instead of tty1.

  • This does not really answer the question. If you have a different question, you can ask it by clicking Ask Question. You can also add a bounty to draw more attention to this question once you have enough reputation. - From Review
    – Fabby
    Jan 16, 2017 at 19:48
  • @Fabby: I think the post is intended as an answer although I'm not sure it's really befitting the question. Jan 16, 2017 at 20:01
  • My answer is similar to @emk2203's and I intended to make a comment under his post, however I do not have sufficient reputation to do so.
    – loongyh
    Jan 17, 2017 at 19:08

This looks like a similar problem I had with a previous Ubuntu. It was installing the boot loader to the Usb drive. I had to manually install a boot loader (grub or whatever) to the internal ssd.

  • As you can see in the last screenshot in the question it is definitely installing the boot loader to /sdc Apr 24, 2016 at 2:08

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.