Comment 30 for bug 1434581

Revision history for this message
Mike Jester (mikejester) wrote :

Understood. I agree that not completely breaking virtual machines in some hypervisors is important. While I'm required to use bare-metal installs on these systems, I depend on VMs as much as the next person. There has to be an alternate solution.

Are you suggesting there's a kernel change needed that shouldn't load vesafb until later? Or are you saying I should set GRUB_TERMINAL=console and do something once it's booted? I can't modprobe vesafb now after all. Sorry if I'm a bit slow on the uptake here -- this is my first rodeo. I am primarily a C++ developer but I have not spent any time in the kernel before.

Unfortunately I can't change the config in any way that would cause regression in production. That includes lowering the resolution or just using 80x24. They're pretty strict on both regression and security here. Also, there is no SSH to these boxes so any interaction I have with them is sitting physically in front of them.

I got some more dmesg outputs and checked /proc/fb on each.

12.04 3.2 and 12.04 3.13 SYSFB=N displayed the same: 0 VESA VGA
12.04 3.13 SYSFB=Y was: 0 simple