Just noticed this post was missing the initial information:
<mdomsch> hpa: your test ISO shows: vesamenu.c32: attempted DOS system
call INT 2C 42C4 D00004F0
<mdomsch> when run under latest F9 virt-manager started KVM machine
<mdomsch> hpa, but does _not_ fail as such when run manually with
<mdomsch> sudo qemu-kvm -M pc -m 512 -hda
/var/lib/libvirt/images/hpa.img -cdrom /var/tmp/boot-fc9-3.70-pre26.iso
<mdomsch> hpa, which means one of these args is probably causing it
<mdomsch> /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name foo -monitor
pty -boot c -drive
file=/var/lib/libvirt/images/foo.img,if=ide,index=0,boot=on -drive
file=,if=ide,media=cdrom,index=2 -net
nic,macaddr=00:16:3e:13:75:3a,vlan=0 -net
tap,fd=13,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb
-vnc 127.0.0.1:0 -k en-us
For what it's worth, it's the "boot=on" part that is causing extboot to
be invoked, which is what is causing the failure.
I have to admit I don't really understand why extboot hooks INT 13h at
all (why emulate a disk on a system where disks are virtual anyway?),
but more seriously, it has the problem that:
a) it uses vectors in OS reserved space;
b) it doesn't clean up after itself after giving up and before invoking
the old INT 19h vector.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
