console in the framebuffer in qemu-kvm is slow, breaks -curses functionality

The fix is quite simple. In rootskel, when loading the fbcon module, we can check if we're running in a QEMU based virtual machine.

=== modified file 'src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86'
--- src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86 2009-04-29 09:59:35 +0000
+++ src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86 2009-11-23 16:34:52 +0000
@@ -1,5 +1,6 @@
 if [ -n "$TERM_FRAMEBUFFER_TRY" ] && \
- [ "$(debconf-get debian-installer/framebuffer)" = true ]; then
+ [ "$(debconf-get debian-installer/framebuffer)" = true ] && \
+ [ ! grep -qs "^model.*QEMU Virtual CPU" /proc/cpuinfo ]; then
        echo "Trying to enable the frame buffer..."
        if grep -q VESA /proc/fb || \
           (modprobe -q vesafb >/dev/null 2>&1 && grep -q . /proc/fb) || \

This bug was fixed in the package rootskel - 1.81ubuntu2

---------------
rootskel (1.81ubuntu2) lucid; urgency=low

  * src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86:
    do not use the frame buffer console, if running in a QEMU/KVM, LP: #487187
 -- Dustin Kirkland <email address hidden> Mon, 23 Nov 2009 11:22:38 -0600

Well, I tried to fix this, but the fix was not acceptable.

To those affected by this, you can try something like the following, to actually edit the ISO inline using sed, and turn the fb off. Note that the replacement will need to be character-for-character:

sed -i "s/initrd.gz quiet --/initrd.gz fb=0 --/" lucid-server-amd64.iso

I created a script, in my $HOME/bin/fixiso:
#!/bin/sh
sed -i "s/initrd.gz quiet --/initrd.gz fb=0 --/" $@

Is there any reason this fix didn't make it into Lucid Beta 1? I attempted to install lucid beta 1 on a QEMU/KVM virtual machine, and was unable to until I added the fb=0 to the boot args.

Because it's too big a hammer - if nothing else, disabling the framebuffer restricts the set of available languages. I'm prepared to put up with slowness for that. You say that you were *unable* to install, though, which I think must mean that you have a slightly different bug, since I haven't heard of this preventing installation for anyone else, unless you're reliant on -curses for some reason.

Like Colin says, it should be slower, but it shouldn't prevent your
installation.

Are you sure that your KVM was running with acceleration?

What is the output of the kvm-ok command?