Ubuntu 14.04 boots to blank console

/etc/defaults/grub:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="vga=789 consoleblank=0"
#GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=800x600
GRUB_GFXPAYLOAD=800x600

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Tested with different vga parameters -- all the same: blank console, but switched to the given size: 800x600.

Had the chance to test on a system not providing 640x480 any more. Only 800x600 and higher are available. Such a system is unusable: even without any vga setting grub is shown, but later, after switching back to 640x480 nothing is drawn any more on screen!

This doesn't seem to be related to util-linux.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1270656

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport-collect fails to login to launchpad after allowing to access on my behalf see: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1270717

The apport data from comment #11 shows a virtual machine on VMWare. Looking at the first dmesg log, there seems to be some kind of resource conflict between the simple-framebuffer driver and vmwgfx. For testing you could probably try to create a file like /etc/modprobe.d/blacklist-testing.conf with a line "blacklist vmwgfx" in it. That should give some console (maybe not the most performant).

[ 0.782125] simple-framebuffer simple-framebuffer.0: framebuffer at 0xe8000000, 0x1d5000 bytes, mapped to 0xffffc90008380000
[ 0.782128] simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=800x600x32, linelength=3200
[ 0.784093] Console: switching to colour frame buffer device 100x37
[ 0.785022] simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
...
[ 21.258191] vmwgfx 0000:00:0f.0: BAR 1: can't reserve [mem 0xe8000000-0xefffffff pref]
[ 21.258193] [drm] It appears like vesafb is loaded. Ignore above error if any.
[ 21.258469] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 21.258471] [drm] No driver support for vblank timestamp query.
[ 21.259320] [drm] Screen objects system initialized
[ 21.259325] [drm] Initialized vmwgfx 2.4.0 20120209 for 0000:00:0f.0 on minor 0

#12: yes this is true, but does not explain why this leads to "blank console" using the ubuntu supplied kernel and not using one self compiled from plain vanilla sources. I've tested since: 3.12.8, 3.13.0-rc8 and 3.13. All show the same result: working console at expected 800x600.

The ubuntu supplied kernel does not show a working console: only black blank screen. It does not matter if within VMware, VirtualBox or on real hardware -- it is all the same: console working if 640x480 but not if set to 800x600 (or even higher -- I just do not set VMs to use higher resolutions because my monitor isn't large enough for more).

Even the working kernel show this conflict -- IMHO it isn't the cause Ubuntu supplied kernels do not work. I've tired to compile an Ubuntu supplied kernel, but failed miserably (I gave up, because I *can* compile plain vanilla ones -- why should I crop with applied patches?).

Within the fb-subsystem there are differences in kernel compile options. Ubuntu kernels use a slightly different setup then I. I'd expect to find the source of this problem there.

It would explain it when this caused the old framebuffer displayed but not updated and the new one updated but not displayed. Anyway, the Ubuntu supplied kernel is quite close to upstream, so its rather some config difference.

Please could you retry with the latest 3.13.0-5 Ubuntu kernel and add the dmesg output of that and one from one of your kernels booted. Thanks.

There are slightly differences in character display depending on which driver is blacklisted.

With my own kernel I could recognize changes in character display while booting.

Blacklisting simple-framebuffer for the Ubuntu kernel will have no effect because it is built-in. But I am interested in the two dmesg's without any blacklisting to compare the output. Somehow those labelled as own kernel seem to be from a boot with the normal Ubuntu kernel, too. Just the wrong dmesg or where were the different kernels installed?

My fault: picked the wrong dmesg-files …!

Ok so with those there seems to be some resolution lines which get repeated three times with the Ubuntu kernel (which is odd) and compared to the self-compiled kernel there seems to be no action to replace the framebuffer.

Could you try to boot the Ubuntu kernel with "vmwgfx.enable_fbdev=1" added to the kernel command-line in grub and report back whether that changes behaviour (also adding the dmesg from that run)?

With this kernel-option I'll get a console prompt, but various kernel log lines are never prinited on screen.

Printing stops at about "[ 54.811735] [drm] DMA map mode: Using physical TTM page addresses." and then starts again after a screen size change at about "[ 57.317174] intel_rapl: domain core energy ctr 0:0 not working, skip".

With the self compiled kernel all lines are printed.

Since today a new version of open-vm-tools is available. I've tested again with this new version. Some of the errors seen with the old version are gone now.

Not sure which errors are gone now. The line related to drm and vmwgfx are like the previous no blacklisting and no setting fbdev dmesg to me. Again repeating the resolution and FIFO line and not replacing the framebuffer.
How the user-space tools would influence the kernel boot I cannot explain. The dkms package that goes with it does not seem to replace anything gfx related.
So loosing a few lines while switching framebuffers is something I would not worry too much about. Though that should be the same with the Ubuntu and your own kernel... We probably should make the default enabled here.
Aside that, something else to try: most newer framebuffer drivers (especially those related to drm drivers) will understand something like "video=800x600" instead of vga=789 (maybe video=simplefb:800x600 but according to dmesg it is already using that resolution). The resolution would be set by GRUB_GFXMODE, GRUB_GFXPAYLOAD is not used when generating the real grub config file.

I had the same problem, but I fixed it by commenting these lines:

# if ([ "$ubuntu_recovery" = 0 ] || [ x$type != xrecovery ]) && \
# ([ "x$GRUB_GFXPAYLOAD_LINUX" != x ] || [ "$gfxpayload_dynamic" = 1 ]); then
# echo " gfxmode \$linux_gfx_mode" | sed "s/^/$submenu_indentation/"
# fi

in /etc/grub.d/10_linux.

I have the same problem. On hardware.
LTS 14.04
GeForce GTX 750
If I enter grub menu choose "Advanced Options For Ubuntu"
Then doing nothing and normally load the system resulting ctrl+alt+F0-F6 becomes working and I see login prompt on text consoles.
Text consoles worked before with the same ubuntu distributive and same hardware. The bug appeared probably after ubuntu reinstallation.

I fear the problem here might be in reality more than one and we should get them into separate reports to make it simpler to work on them. The symptom and maybe the overall problem might be the same but each graphics type will need to be addressed individually. This report was initially about vmwgfx. @Thomas, just for the records, do you still have any issues?

Sergio, beside opening a new bug to have your specific hardware setup recorded there, have you ever tried to enable the commented out line in /etc/default/grub that enables text mode for the grub menu. Probably for debugging one also wants to comment out the two lines about hidden timeout. This brings up the grub menu on reboot without playing tricks with pressing left shift at the right time (which I never manage). Make sure to run "sudo update-grub" after changing that file.

From slipch it would be important to know whether the nouveau or the nvidia binary gfx driver is in use. But that should be automatically included when filing bugs by running "ubuntu-bug linux". Since there is no GUI up in the problem case this would have to be done after booting with whatever workaround you have. Best after a "bad" boot since then /var/log/syslog should have the info of the previous boot, too.I would also suggest to include the driver in the title line (eg. ... boots to blank console with nouveau).

After creating new bug reports, please add a comment here to report the bug number(s). Thanks.

Looks like since the later updates the bug seems gone -- at least for vmwares graphics drivers.
On an other system running on real hardware the bug seems gone too.

I'll check later today on my laptop -- hopefully it is history there too!

With my laptop the problem is gone using my self compiled kernel or the latest one from Ubuntu. It is there using some older kernels. I had to carefully adjust "vga=xxx" to switch to the very same mode than gfxpayload set to 1280x800@32. Took some time and playing around until it worked as expected.
After compiling in all deprecated mode-switching stuff into the kernel I didn't have any problems any more. Looks a lot like bugs in mode handling with the kernel and/or grub2. Even access restrictions may be the case, because I saw some non fatal warnings about write restricted warnings hushing by while the kernel initialized.
But the main point was to keep all deprecated mode-switching stuff in to have graphics work as expected -- seems there are a lot of parts within all the graphics code depending on these, breaking if they are not available.

As far as I remember we changed CONFIG_DRM_VMWGFX_FBCON to 'y ' now. Generally it is getting more complicated nowadays. Grub2 initializes some framebuffer graphics mode (unless console mode is enforced in /etc/default/grub), hands this fb over to plymouth and that hands things over to X. And somewhere between grub and plymouth starting, the kernel may start a gfx device specific modeset driver which may have its own fb driver. Many opportunities for things to go wrong. Btw, I think I mentioned it before but the vga= argument may be becoming more a problem than helping. Grub sets a gfx mode already and that is kept if no modeset driver is not changing it. And all newer modeset drivers use video= for specifying the preferred resolution. (like video=1280x800@32). But in theory that should not be necessary at all when the gfx mode is set ok by grub.
Anyway, I tend to declare this bug as "fixed" and have people with other gfx cards/drivers open individual bug reports. Mixing things in one single report will only cause confusion.

Seems fixed now

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

  With the recent release of this Ubuntu release, would like to confirm if this bug is still present. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.