I've encountered a problem with Debian Squeeze. Wheezy doesn't seem to have a
bigmem kernel, so I can't test it there.
I have a custom firewall based on Smoothwall. I've been testing it (kernel
2.6.35 with PAE and SMP) on Squeeze in KVM without trouble for a couple years.
When I upgraded my firewall's kernel to 3.0, it would no longer boot in KVM.
Instead, it hangs right after displaying the first three lines on the console,
and the host CPU goes to 100%. Trying other kernels, I found that none of 3.0,
3.2 or 3.4 will boot.
Investigating further, I found that those kernels *will* boot if I use
Debian's x86 or x86_64 kernel. But they *won't* boot when using Squeeze's
bigmem (PAE) kernel.
I tried both Squeeze's kvm as well as a build of qemu-kvm 1.1.x.
In a sentence, my 3.x kernels with PAE and SMP will not boot in KVM on Squeeze
when using a bigmem (PAE) kernel, but they *do* boot when using Squeeze's 686
or x86_64 kernel, as well as Wheezy's x86_64 kernel.
Can anyone verify this, or is it just me? Is it possible I missed a kernel
config parameter required to allow the PAE-enabled kernel to boot in a KVM
session? Could it be a Debian build problem? An upstream kernel problem? Or a
Here's an example ISO (29MiB, linux 3.4.9):
Select the 'Explore' option from the boot menu.
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
Archive: firstname.lastname@example.org">htt p://email@example.com
09-13-2012, 05:22 PM
kernels 3.0, 3.2, 3.4 won't boot in KVM
> Can anyone verify this, or is it just me? Is it possible I missed a kernel
> config parameter required to allow the PAE-enabled kernel to boot in a KVM
> session? Could it be a Debian build problem? An upstream kernel problem? Or a
> qemu-kvm problem?
I was able to boot the ISO you've provided using qemu-kvm from backports.
Didn't test anything else, though.
Host system is Debian Squeeze, qemu-kvm version is 1.0+dfsg-8~bpo60+1.
I've attached full boot log taken from serial console just in case.
Apparently, the trick is to tell qemu-kvm not to strip an 'lm' processor bit, i.e
present a guest CPU as x86_64, not i686.