This is worrying since libvirt always uses boot=on

Using boot=on makes us use a different code path which most people testing upstream only use for booting with virtio

Not denying this is an bug with the extboot ROM, but ...

Lilo also fails to boot from hdc when boot=on is used, with the message:

  LILO - Keytable read/checksum error

This happens even if lilo is installed from within a kvm running with boot=on.
Without boot=on everything works fine.

Good: qemu-kvm -M pc -m 128 -smp 1 -drive file=test.img,if=ide,index=2

Bad:  qemu-kvm -M pc -m 128 -smp 1 -drive file=test.img,if=ide,index=2,boot=on

I had the same situation, but with installed Slackware 12.1 by virt-manager.

When I set up booting from hard disk drive I had in my /etc/libvirt/qemu/s12.1.xml:
  ...
  <boot dev='hd'/>
  ...
and when I started I got:
   LILO - Keytable read/checksum error

After changing to boot from CDROM, my xml changed:
  ...
  <boot dev='cdrom'/>
  ...
and when after I've started virtual machine I pressed F10 and choiced boot from hd and everything goes right!
I checked - in this case QUEMU started without this option boot=on!

Jacek, could I have your full XML file , and qemu command line? (this should be the output of /var/log/libvirt/qemu/s12.1.log)

Working configuration:

<domain type='kvm'>
  <name>s12.1wzor</name>
  <uuid>11bf4e1c-a210-3b9b-dd1e-2038de7d4428</uuid>
  <memory>262144</memory>
  <currentMemory>131072</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='i686' machine='pc'>hvm</type>
    <boot dev='cdrom'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>   
  <on_crash>restart</on_crash>
  <devices>
    <disk type='block' device='disk'>
      <source dev='/dev/sda8'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='file' device='cdrom'>
      <source file='/mnt/slak/home/jack/slack/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <interface type='network'>
      <mac address='00:16:3e:66:b4:76'/>
      <source network='default'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/13'/>
      <target port='0'/>
    </serial>
    <console type='pty' tty='/dev/pts/13'>
      <source path='/dev/pts/13'/>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
  </devices>
</domain>

... and respectively log:

/usr/bin/qemu-kvm -S -M pc -m 128 -smp 1 -name s12.1 -monitor pty -boot d -drive file=/dev/sda8,if=ide,index=0 -drive file=/mnt/slak/home/jack/slack/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:66:b4:76,vlan=0 -net tap,fd=14,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:1 
char device redirected to /dev/pts/10
char device redirected to /dev/pts/11
info cpus

Bad one:
<domain type='kvm'>
  <name>s12.1wzor</name>
  <uuid>11bf4e1c-a210-3b9b-dd1e-2038de7d4428</uuid>
  <memory>262144</memory>
  <currentMemory>131072</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='i686' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>   
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='block' device='disk'>
      <source dev='/dev/sda8'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='file' device='cdrom'>
      <source file='/mnt/slak/home/jack/slack/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <interface type='network'>
      <mac address='00:16:3e:66:b4:76'/>
      <source network='default'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/11'/>
      <target port='0'/>
    </serial>
    <console type='pty' tty='/dev/pts/11'>
      <source path='/dev/pts/11'/>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
  </devices>
</domain>

and log:

/usr/bin/qemu-kvm -S -M pc -m 128 -smp 1 -name s12.1wzor -monitor pty -boot c -drive file=/dev/sda8,if=ide,index=0,boot=on -drive file=/mnt/slak/home/jack/slack/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:66:b4:76,vlan=0 -net tap,fd=14,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:1 
char device redirected to /dev/pts/10
char device redirected to /dev/pts/11
info cpus

.. and obviously I've got:

  LILO - Keytable ....etc.

Files differs only in qemu: boot=on and option in XML: <boot dev='hd'/> or <boot dev='cdrom'/>

I hope it helps find bug! Maybe it something in qemu?
Good luck!

Just reproduced this bug.

I'll be digging into it during the next days.

Could you test the following build ?

http://koji.fedoraproject.org/koji/taskinfo?taskID=967966

grab the rpm for your architecture and give it a go. Also, this bug probably also happens on F-10. If you can confirm it and clone it, I'll post a fix for it too.

(In reply to comment #7)
Tested the x86_64 build on F-9 and I can confirm it fixes the lilo issue
in comment #2.

In my case, on Fedora 10 x86_64, running through virt-manager, I get
"Windows 2000 could not start because the following file is missing or corrupt:
\WINNT\SYSTEM32\CONFIG\SYSTEM"

That's unless I copy the virtual machine across again from Fedora 9, in which case it boots -- once. When I shut it down and start again, then I get the same failure.

Or unless I use Jacek's workaround, in which case it boots fine.

I'd certainly like to test a fixed build.

Thanks!

James,

Especially because you're not running F9, this seems like a different issue.

Can you please open a new request that covers your case?

Thanks!

kvm-65-13.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kvm-65-13.fc9

kvm-65-13.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update kvm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10723

kvm-65-15.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kvm-65-15.fc9

kvm-65-15.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

kvm-65-15.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.