Bug 464304

Summary: 'boot=on' options makes w2k guests fail to start
Product: [Fedora] Fedora Reporter: Enrico Scholz <rh-bugzilla>
Component: kvmAssignee: Glauber Costa <gcosta>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: badjack, berrange, bugzilla, clalance, devel, gcosta, markmc
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-24 12:58:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 474059    

Description Enrico Scholz 2008-09-27 11:35:04 UTC
Description of problem:

When 'boot=on' option is given for a disk, the w2k guest fails to
start because it can not find 'ntfs.sys' (this happens very early).

Guest starts fine when removing this option.

E.g.

Good: /usr/bin/qemu-kvm -M pc -m 256 -smp 1 -name win2k -localtime -boot c -drive file=/srv/qemu/win2k/nt.img,if=ide,index=0 -drive file=/srv/qemu/win2k/nt-d.img,if=ide,index=1 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0

Bad:  /usr/bin/qemu-kvm -M pc -m 256 -smp 1 -name win2k -localtime -boot c -drive file=/srv/qemu/win2k/nt.img,if=ide,index=0,boot=on -drive file=/srv/qemu/win2k/nt-d.img,if=ide,index=1 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0
                                                                                                                            ~~~~~~~~


Both files are raw images; it's a i386 guest on a 64 bit host.


Version-Release number of selected component (if applicable):

kvm-65-9.fc9.x86_64

Comment 1 Mark McLoughlin 2008-11-07 10:37:44 UTC
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 ...

Comment 2 Marcus Sundberg 2008-11-20 17:51:12 UTC
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

Comment 3 Jacek Pietrewicz 2008-11-26 16:27:55 UTC
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!

Comment 4 Glauber Costa 2008-11-26 18:01:07 UTC
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)

Comment 5 Jacek Pietrewicz 2008-11-27 08:49:15 UTC
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!

Comment 6 Glauber Costa 2008-11-27 11:22:41 UTC
Just reproduced this bug.

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

Comment 7 Glauber Costa 2008-12-01 20:10:21 UTC
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.

Comment 8 Marcus Sundberg 2008-12-01 20:56:46 UTC
(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.

Comment 9 James Wilkinson 2008-12-01 21:46:16 UTC
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!

Comment 10 Glauber Costa 2008-12-01 22:23:38 UTC
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!

Comment 11 Fedora Update System 2008-12-02 15:54:28 UTC
kvm-65-13.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kvm-65-13.fc9

Comment 12 Fedora Update System 2008-12-07 04:11:13 UTC
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

Comment 13 Fedora Update System 2008-12-22 19:51:49 UTC
kvm-65-15.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kvm-65-15.fc9

Comment 14 Fedora Update System 2008-12-24 12:58:09 UTC
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.

Comment 15 Fedora Update System 2008-12-24 18:40:46 UTC
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.