Guest not keeping VESA console resolution

[Baer]

I am in the process of moving a Linux Mint 18.3 (based on Ubuntu 16.04 LTS) guest from VMware Workstation to VirtualBox. My host OS is Windows 7x64. This is what I have done so far:

• Converted the VMware vmdk hard disk file to a VirtualBox vdi file.
• Setup the virtual machine, launched it, removed installed VMware guest additions, installed VirtualBox guest additions.
• Added a 1280x720x32 as "CustomVideoMode1" for my grub.
• Added a 1680x1050x8 as "CustomVideoMode2" for my linux console.

This guest installation does not automatically boot into x11. It boots console mode and x11 is launched if needed after console login (via startx). x11, If launched, runs 1680x1050x32 graphics mode.

The virtual machine is setup to run full screen. This is what happenes during the boot process:

• grub shows its boot manager screen using 1280x720 resolution (as intended)
• linux kernel switches console to 1680x1050x8 (as intended)
• linux kernel switches console font to "terminus" (as intended)
• linux kernel displays the Mint splash logo
• linux kernel switches back to console - changing console mode to 1024x768!

I have no idea why this happenes. This is not a problem of guest additions, they are not active at this point. This is not a problem under VMware ... so "something" which is VirtualBox specific causes the linux console to revert back to 1024x768 (which probably is kind of a VESA default).
Can anyone help me with this? What would I have to look for in the linux log files?

Any hints will be greatly appreciated,
Baer

[mpack]

At any time, VirtualBox gives the virtual display whatever size the guest OS asks for. Adding additional available modes doesn't force a guest to use them. It'll be the guest OS you need to configure, not VirtualBox.

The only thing that slightly surprises me is that when you switch back to console mode you say it's still in fact running in a graphics mode, not a text mode? If so then I assume that's a feature of your guest OS.

[Baer]

...
The only thing that slightly surprises me is that when you switch back to console mode you say it's still in fact running in a graphics mode, not a text mode? If so then I assume that's a feature of your guest OS.

Running a text console in graphics mode is a feature of any linux flavor since forever. It dates back to the SUN workstations. Do you remember?

Anyway, I found the bad guy. It is vboxvideo - the video driver. Whenever this driver switches back from x11 graphics mode to console mode, it switches to a 800x600 (not 1024x768, I eyeballed that wrong) graphics mode using a 8x16 pixel (VGA) character generator. vboxvideo simply does not care about what the console mode should be.
There are numerous (old) reports about this problem. But actually, it will get worse these days (at least when not running scaled mode) with high resultion displays.

Just in case support is reading here: is this ever going to be fixed? Because there is a world beyond graphic desktop environments.

Thank You,
Baer

[socratis]

You do realize that when in text-only mode, the vboxvideo is not even involved, right? Check the configuration of your guest. Make sure it can be made to run on a console mode that's more than 800x600. It may not be able to do it. DOS for example is restricted to 640x480, no matter what size you were planning on growing it to.

[mpack]

For me to remember Sun workstations I'd have to be remembering a different life - I came up through DOS and Windows and embedded processors (bare metal).

That 800x600 switch is exactly what I would expect - VirtualBox is switching to an emulated SVGA text mode, which of course is implemented using a host graphical window. SVGA had a limited range of text mode sizes (basically corresponding to an 80x25 or 80x43 frame multiplied by the ROM font dimensions), so of course your graphics mode hints aren't relevant.

[Baer]

You do realize that when in text-only mode, the vboxvideo is not even involved, right? Check the configuration of your guest. Make sure it can be made to run on a console mode that's more than 800x600. It may not be able to do it. DOS for example is restricted to 640x480, no matter what size you were planning on growing it to.

And you do realize that you need to brush up on your Linux knowledge, right? Ever heard of KMS?
Anyway, the video driver used by X11 (vboxvideo) is a kernel driver. It is loaded during the boot process and enables the operation of X11 as well as the (usually 6) text consoles. You might want to actually read a syslog to see what is going on during the boot process. So here we go:

• The boot loader (grub) can use its own graphics mode (or a real text mode). It also passes information to the selected kernel about which mode (text or graphics) the Linux kernel shall use for its consoles.
• Grub's own video mode and Linux's video mode do not have to be the same. Grub has different configuration variables for both modes. Both modes, however, have to be valid VESA modes.
  Since my monitor's native resolution is 1680x1050 I added this resolution to the virtual machine's VESA modes in order to be able to use it in Linux console text mode.
• The Linux kernel starts booting, it sets the text console according to Grub's orders (1680x1050) and also sets a 10x22 pixel Terminus font for my console. This all works fine. I can see it.
• Later in the boot process vboxvideo gets activated. It is loaded and run for the reason of initializing the 6 user text consoles and also to display a splash boot logo (if activated).
• Now I do understand that VirtualBox does not support real (aka hardware) text mode, not even in full screen mode (VMware would'nt either). So in case the Linux console is currently in hardware text mode, vboxvideo switches the text mode to 800x600 using a 8x16 vga character generator. VMware would do the same.
• The bug is - vboxvideo does this regardless of the initial console video mode. If the initial console video mode (as preset by grub) is not a hardware text mode but a graphics mode, it still overrides it, although this does not make any sense! VMware only overrides the initial console mode if that is a hardware text mode.

To prove that I am right I blacklisted vboxvideo. As a result the Linux kernel picks vesafb, the next best choice to manage the video system. And guess what: I have perfect text consoles in 1680x1050 with my chosen 10x22 Terminus font. Of course it would need some tweaking of X11 (writing a xorg.conf) to force X11 to use vesafb and eventually that would work (I did this years ago when a certain version of the VMware video driver was buggy) but actually I don't want to do this because using vesafb under X11 would result in having no graphics acceleration at all.

Still trying to make my point:

• VirtualBox host gives the guest whichever video mode it wants (as long as that is a standard or user defined VESA mode).
• My guest is totally capable of displaying the video modes I want to use.
• vboxvideo simply does not care about the kernel's initial console video mode and forces a 800x600 graphics modes no matter what. This enforcement is only necessary if the initial Linux console mode is a hardware text mode. Destroying a valid graphics console setup is a bug, not a feature - unless there is a kernel parameter to tell vboxvideo to keep the Linux console in its initial graphics mode.

Baer

[mpack]

If it's not using a ROM font then it isn't a text mode. If it's letting you choose any size you want then it isn't a text mode. Text modes predate VESA. I won't swear that VESA never included an option to switch back to text mode, but VESA is primarily a graphics standard.

I believe that VirtualBox is emulating a text mode terminal, based on the requests of the guest OS. I believe it is NOT selecting a graphics mode displaying a software defined text font, which I rather suspect you are confusing with text mode.

[michael]

I never took the time to implement anything other than 800x600 for text consoles, and unfortunately do not plan to, as I am short of time for things which seam more important to me. If you can fix it yourself we might be able to integrate the fix (or perhaps you could find some way of making it work by fiddling...)

Regards
Michael