Ubuntu boot in Oracle VirtualBox ends up with a corrupted display

Bug #1443853 reported by V字龍(Vdragon) on 2015-04-14
110
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Virtualbox
Invalid
Unknown
console-setup (Ubuntu)
Critical
Unassigned
kbd (Ubuntu)
High
Unassigned
virtualbox (Ubuntu)
Critical
Unassigned

Bug Description

(Content copied from "Ubuntu 14.10 ISO live boot ends up with a corrupted display" #13615 VirtualBox bug ticket, by piotrjurkiewicz)

Booting up live session of Ubuntu MATE 14.10 and Ubuntu Gnome 14.10 from ISO ends up with a corrupted screen. See the screenshot:
https://launchpadlibrarian.net/186864347/ubu.png

Switching back and forth to the tty7 (ctrl+alt+F1 and then alt+F7) fixes the display.

I think that this might be a problem with resolution setting:

```
00:00:31.226379 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=0000000000000000 w=1152 h=400 bpp=0 cbLine=0x0, flags=0x1
00:00:31.226399 UIFrameBuffer::RequestResize: Screen=0, Format=0, BitsPerPixel=0, BytesPerLine=0, Size=1152x400, Sending to async-handler..
00:00:31.226457 UIFrameBufferQImage::resizeEvent: Format=0, BitsPerPixel=0, BytesPerLine=0, Size=1152x400
00:00:31.226467 UIFrameBufferQImage::resizeEvent: Resizing to FALLBACK buffer due to format is invalid..
```

After switching back and forth to the tty7 (what fixes the display) the log says:

```
00:00:31.226379 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=0000000000000000 w=1152 h=400 bpp=0 cbLine=0x0, flags=0x1
00:00:31.226399 UIFrameBuffer::RequestResize: Screen=0, Format=0, BitsPerPixel=0, BytesPerLine=0, Size=1152x400, Sending to async-handler..
00:00:31.226457 UIFrameBufferQImage::resizeEvent: Format=0, BitsPerPixel=0, BytesPerLine=0, Size=1152x400
00:00:31.226467 UIFrameBufferQImage::resizeEvent: Resizing to FALLBACK buffer due to format is invalid..
00:01:37.584616 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0, flags=0x1
00:01:37.584634 UIFrameBuffer::RequestResize: Screen=0, Format=0, BitsPerPixel=0, BytesPerLine=0, Size=720x400, Sending to async-handler..
00:01:37.584680 UIFrameBufferQImage::resizeEvent: Format=0, BitsPerPixel=0, BytesPerLine=0, Size=720x400
00:01:37.584692 UIFrameBufferQImage::resizeEvent: Resizing to FALLBACK buffer due to format is invalid..
00:01:39.055475 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=000000000a7f0000 w=1024 h=768 bpp=32 cbLine=0x1000, flags=0x1
00:01:39.055495 UIFrameBuffer::RequestResize: Screen=0, Format=843204434, BitsPerPixel=32, BytesPerLine=4096, Size=1024x768, Sending to async-handler..
00:01:39.055559 UIFrameBufferQImage::resizeEvent: Format=843204434, BitsPerPixel=32, BytesPerLine=4096, Size=1024x768
00:01:39.055568 UIFrameBufferQImage::resizeEvent: Resizing to directly use VGA device content..
```

I have tested 4.3.18 and also the testbuild 4.3.19 r96825, it happens on both of them.

You can download the ISO images of these two systems here:

 https://ubuntu-mate.r.worldssl.net/download/ubuntu-mate-14.10-desktop-amd64.iso

 http://cdimage.ubuntu.com/ubuntu-gnome/releases/14.10/release/ubuntu-gnome-14.10-desktop-amd64.iso

summary: - Ubuntu 14.10 ISO live boot ends up with a corrupted display
+ Ubuntu 14.10 ISO live boot in VirtualBox ends up with a corrupted
+ display
Changed in virtualbox:
status: Unknown → New
summary: - Ubuntu 14.10 ISO live boot in VirtualBox ends up with a corrupted
+ Ubuntu 14.10 ISO live boot in Oracle VirtualBox ends up with a corrupted
display

Please see comment 1[1] and 14[2] on that ticket. We believe that this is a problem in setfont, not in VirtualBox (or Ubuntu for that matter).

[1] https://www.virtualbox.org/ticket/13615#comment:1
[2] https://www.virtualbox.org/ticket/13615#comment:14

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in console-setup (Ubuntu):
status: New → Confirmed
Changed in kbd (Ubuntu):
status: New → Confirmed
Changed in virtualbox (Ubuntu):
status: New → Confirmed
Changed in virtualbox:
status: New → Invalid
rogerdpack (rogerpack2005) wrote :

I just got this with 16.04 and virtualbox 5.1.2

So whose bug is this exactly? It results in a poor installation experience in virtualbox, unfortunately. Never run into it before now.

Unfortunately I'm trying to trace it down, which host/guest iso do you have? which architecture?

according to upstream vbox, it is not a vbox bug, just it happens more often on VM

Changed in virtualbox (Ubuntu):
status: Confirmed → Incomplete
Michael Thayer (michael-thayer) wrote :

I think that in this day and age EGA console fonts are meaningless for 99% of the user base or more. I also think that if you remove the functionality the remaining 1% will complain very loudly. However, I suspect that many of those will have set up custom fonts to be loaded. So my suggested fix is to comment out everything in /etc/default/console-setup. Then the code will just not execute for users who have not set up custom fonts.

Someone who actually understands the details of this should check whether this makes sense before implementing it.

If you do actually find someone at Ubuntu who knows about this, perhaps you can ask them to comment on this thread:

https://www.virtualbox.org/pipermail/vbox-dev/2016-July/013926.html

I note that the person asking the question seemingly never bothered to create an Ubuntu bug, so it can't have been that important to them.

Daniel Lange (dlange) wrote :

Work around:
# use the following command to switch to VT1 from outside the VM:
VBoxManage controlvm "Ubuntu 16.04" keyboardputscancode 1D 38 3B 9D B8 CB
# inside the VM, log in and then insert # in front of all variable assignments as to @michael-thayer above:
sudo nano -w /etc/default/console-setup
# finally reboot
sudo reboot

Jure Sah (dustwolfy) wrote :

Also affects Ubuntu 16.04 LTS.

S. McCandlish (smccandlish) wrote :

Re: "I note that the person asking the question seemingly never bothered to create an Ubuntu bug, so it can't have been that important to them." That's not actually a safe assumption at all. Many people are on the clock and are not paid to file bug reports for the rest of the world. As soon they find a work-around that deals with the problem temporarily and locally, they move on. This problem has been reported world-wide in multiple circumstances, and is still happening with 16.04. It just happened to me right now (with the Xubunutu 16.04.1 ISO in a VirtualBox VM). The Right-Ctrl F1 and Right-Ctrl F7 (or "Host" F1, "Host" F7, if you've redefined the "Host" key) trick worked for me in this case, so I'm done with it and getting back to work. It is possible I (or someone in my situation) might remember to try to replicate and debug this problem further for everyone, on a VM at home, on our own time. But Canonical cannot depend on this happening. It's a "bad administrator experience" issue that should be dealt with like any other serious bug.

Download full text (4.9 KiB)

Hello,

Short answer (mobile mail). On the whole a bug with a workaround is usually (understandably) less important to people than one without. I am slightly surprised that Canonical have not looked at this since I have provided a fix which may well be acceptable as is, but of course I do not presume to try to tell them what their priorities should be.

Regards,

Michael

On 30. August 2016 02:58:14 GMT+03:00, "S. McCandlish" <email address hidden> wrote:
>Re: "I note that the person asking the question seemingly never
>bothered
>to create an Ubuntu bug, so it can't have been that important to them."
>That's not actually a safe assumption at all. Many people are on the
>clock and are not paid to file bug reports for the rest of the world.
>As
>soon they find a work-around that deals with the problem temporarily
>and
>locally, they move on. This problem has been reported world-wide in
>multiple circumstances, and is still happening with 16.04. It just
>happened to me right now (with the Xubunutu 16.04.1 ISO in a VirtualBox
>VM). The Right-Ctrl F1 and Right-Ctrl F7 (or "Host" F1, "Host" F7, if
>you've redefined the "Host" key) trick worked for me in this case, so
>I'm done with it and getting back to work. It is possible I (or
>someone
>in my situation) might remember to try to replicate and debug this
>problem further for everyone, on a VM at home, on our own time. But
>Canonical cannot depend on this happening. It's a "bad administrator
>experience" issue that should be dealt with like any other serious bug.
>
>--
>You received this bug notification because you are subscribed to the
>bug
>report.
>https://bugs.launchpad.net/bugs/1443853
>
>Title:
> Ubuntu 14.10 ISO live boot in Oracle VirtualBox ends up with a
> corrupted display
>
>Status in Virtualbox:
> Invalid
>Status in console-setup package in Ubuntu:
> Confirmed
>Status in kbd package in Ubuntu:
> Confirmed
>Status in virtualbox package in Ubuntu:
> Incomplete
>
>Bug description:
> (Content copied from "Ubuntu 14.10 ISO live boot ends up with a
> corrupted display" #13615 VirtualBox bug ticket, by piotrjurkiewicz)
>
>Booting up live session of Ubuntu MATE 14.10 and Ubuntu Gnome 14.10
>from ISO ends up with a corrupted screen. See the screenshot:
> https://launchpadlibrarian.net/186864347/ubu.png
>
> Switching back and forth to the tty7 (ctrl+alt+F1 and then alt+F7)
> fixes the display.
>
> I think that this might be a problem with resolution setting:
>
> ```
>00:00:31.226379 Display::handleDisplayResize(): uScreenId = 0,
>pvVRAM=0000000000000000 w=1152 h=400 bpp=0 cbLine=0x0, flags=0x1
>00:00:31.226399 UIFrameBuffer::RequestResize: Screen=0, Format=0,
>BitsPerPixel=0, BytesPerLine=0, Size=1152x400, Sending to
>async-handler..
>00:00:31.226457 UIFrameBufferQImage::resizeEvent: Format=0,
>BitsPerPixel=0, BytesPerLine=0, Size=1152x400
>00:00:31.226467 UIFrameBufferQImage::resizeEvent: Resizing to FALLBACK
>buffer due to format is invalid..
> ```
>
> After switching back and forth to the tty7 (what fixes the display)
> the log says:
>
> ```
>00:00:31.226379 Display::handleDisplayResize(): uScreenId = 0,
>pvVRAM=0000000000000000 w=1152 h=400 bpp=0 cbLine=0x0, flags=0x...

Read more...

setting the severity to critical, I really think we should fix this bug, if we can find somebody understanding the console-setup bits

Changed in console-setup (Ubuntu):
importance: Undecided → High
Changed in kbd (Ubuntu):
importance: Undecided → High
Changed in virtualbox (Ubuntu):
importance: Undecided → High
Changed in console-setup (Ubuntu):
importance: High → Critical
Changed in virtualbox (Ubuntu):
importance: High → Critical

I'm setting it to incomplete, because with the vboxvideo driver loaded in the kernel, I can't reproduce this issue anymore
(I might even not able to reproduce it because of my new laptop with different hw configuration)

Changed in kbd (Ubuntu):
status: Confirmed → Incomplete
Changed in console-setup (Ubuntu):
status: Confirmed → Incomplete

this problem again confirmed for Ubuntu 16.04.1 on i386 during the install into virtual box 5.1.6

the amount of people affected is assumed to be high and thus even if there is a work around (but not anybody gets it fast enough how to solve that but rather assume its just broken) it still would serve the Linux community much better if those issue is simply fixed and thus never seen.

I *think* we fixed this for the upcoming ubuntu zesty, I backported the fix, can you please try it?

https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa

thanks

Gianfranco, now I am interested - could you point me to the change you mean?

Hi Michael, I mean this change
https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=17ee2def5d1b193f63fc378eda32d1bc9ead73cb

but you are right, I commented on the wrong bug report. silly me

Norbert (nrbrtx) wrote :

Get this issue on Ubuntu 12.04.5 amd64 host using VirtualBox 5.1.10 with Ubuntu 16.04.1 x86 guest.
The screen shows rainbow of pixels, not the desktop. Turning off 3D acceleration does not solve the problem.
Pressing right Ctrl+F1, then Ctrl+F7 solved the problem.

Dear Ubuntu developers, please fix this problem or contact VirtualBox developers. VirtualBox-way is the easiest to get first impression of Ubuntu. So it is expected that Ubuntu will work on VirtualBox without special actions.

Phillip Susi (psusi) on 2016-12-21
Changed in console-setup (Ubuntu):
status: Incomplete → Triaged
Changed in kbd (Ubuntu):
status: Incomplete → Triaged
Changed in virtualbox (Ubuntu):
status: Incomplete → Triaged
summary: - Ubuntu 14.10 ISO live boot in Oracle VirtualBox ends up with a corrupted
- display
+ Ubuntu boot in Oracle VirtualBox ends up with a corrupted display

It affects Ubuntu-MATE 16.04.1, both 32 and 64bit but it seems to be more Ubuntu and less MATE for in Mint MATE 18.1 (=16.04.1) this problem does not occur. At least I have never seen this in Mint. I need right-ctrl-F1, then right-ctrl F7 (a black screen with blinking cursor appears) and then right-ctrl-F1 again to finally see the desktop allowing to either run the "Try" or "Install" choices.

Interesting to notice: In Linux Mint MATE the "Live-ISO" understands the correct sequence Right-crtl-F7 for the desktop and Right-ctrl-F1 for the first terminal right away, where Ubuntu-MATE does not do so. Any Ctrl-F other than F1 gives a blank "terminal" with just a cursor and no login prompt at all. After installing Ubuntu-MATE this problem is gone and that too follows the correct sequence and shows the login on the available terminals.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.