fancy isolinux screen on install isos hang xen/kvm HVM guests

Bug #83642 reported by John Clemens on 2007-02-06
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu
Undecided
Unassigned

Bug Description

I'm working with ubuntu on Xen right now, and this is a very bad problem. Both the server and desktop install CD's, for both dapper and edgy, use fancy full screen (vbe based?) isolinux install screens. Could we please do away with these screens on the server or alternate install CD? These fancy screens are causing fully virtualized guests that try to boot from these CD's to crash before the boot screen is even drawn. This is true for both Xen and KVM.

To clarify, this does not cause the -host- to crash, just the guest, but you get a blank screen and wonder what happened.

Background (mostly speculation, but I think it's right):
Intel designed VT in a strange way, such that only protected mode instructions are allowed o be virtualized. Anything done in real mode must be emulated...every instruction. The Xen and KVM folks have emulated enough to get things working, but have not handled every instruction, including apparently some of the fancy (VBE?) graphics isolinux on the ubuntu boot cd's is using. (FreeBSD's btx loader also has problems)

For reference, AMD's SVM analogue does, in fact, virtualize real mode instructions on the processor, and I'm able to boot all install CD's just fine on an AMD machine. This is an Intel VT .... 'quirk'.

The mini.iso network install CD loads just fine and works, and I can install over an emulated network. And that CD includes a splash screen w/ isolinux, so it's not all VBE operations that cause problems. You should still be able to have a splash screen, but more then that might cause the problems.

I've filed a bug against Xen about this, and I just tried KVM and ran into the same issue, so I'm assuming it's th same problem. But until the Xen folks figure out what instructions need to be emulated, and take enough time to care, or Intel comes out with an updated VT implementation that does what AMD's does, we can't just boot up a ubuntu install CD on virtual machines and have it work.

My requested solution is that isolinux use just the standard (preferably text) menu and options on the server and/or alternate install CD. Having one full, officially supported install CD that doesn't crash Xen/KVM when trying to install a ubuntu would go a long way towards helping those of us trying to use ubuntu in a virtual environment out. Besides, while I really appreciate all the fancy boot options for a desktop machine, but I would prefer a plain text option for servers anyway. I do, however, see why some would like the opposite.

Would it be possible to get the feisty 'server' install CD to forgo the fancy bootup options?

NOTE: I think I understand what's going on, but if I'm missing something obvious, please tell me.

John Clemens (clemej) wrote :

To reproduce:

Either install Xen, and try booting a HVM xen guest with one of the edgy or dapper full install cd's. Or:

- Install feisty on an intel machine with VT enabled.
- apt-get install kvm
- sudo modprobe kvm-intel
- sudo kvm -m 128 -cdrom <path to edgy server iso> -boot d

witness the empty black box that comes up after the bios messages.

- close that window.
- repeat with '-cdrom <path to edgy mini.iso>' and witness it work as expected.

Aurelien Naldi (aurelien.naldi) wrote :

I can confirm this bug. Running the desktop-cd with qemu (or without loading kvm-intel module) seems to work but is damn slow.
X seems to run inside kvm without a problem, only the early "bling" fails.

This happens because Intel VT does not emulate real mode calls, as explained in the KVM FAQ. I would very much support the idea of not using real mode calls for fancy boot screens thus.

Oleksij Rempel (olerem) wrote :

Seems like hardy new livecd include work around for this and can boot, at leas on my intel pentium d 940.

The problem was with the real->protected switch of gfxboot, relying on some stale values in the processor, which is a corner case of x86 which just can not be efficiently emulated. Xen recently (-unstable tree as of today, i.e. 3.3) switched to emulating all realmode instructions, so this is not a problem any more for Xen.

Omega (atrauzzi) wrote :

This is still a problem in the beta version of Ubuntu Hardy Heron. Any chance of not having this problem present at release? It manifests itself a little strangely in the virt ui....

trollord (trollenlord) wrote :

Well, I installed Ubuntu on Xen and had no such problem. The problem seems to be fixed.

Gabriel Bauman (gabrielbauman) wrote :

This is still the case in Intrepid with KVM.

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

Other bug subscribers