Bug 464304 - 'boot=on' options makes w2k guests fail to start
'boot=on' options makes w2k guests fail to start
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kvm (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Glauber Costa
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 474059
  Show dependency treegraph
 
Reported: 2008-09-27 07:35 EDT by Enrico Scholz
Modified: 2008-12-24 13:40 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-24 07:58:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2008-09-27 07:35:04 EDT
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 05:37:44 EST
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 12:51:12 EST
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 11:27:55 EST
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 13:01:07 EST
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 03:49:15 EST
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 06:22:41 EST
Just reproduced this bug.

I'll be digging into it during the next days.
Comment 7 Glauber Costa 2008-12-01 15:10:21 EST
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 15:56:46 EST
(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 16:46:16 EST
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 17:23:38 EST
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 10:54:28 EST
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-06 23:11:13 EST
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 14:51:49 EST
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 07:58:09 EST
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 13:40:46 EST
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.

Note You need to log in before you can comment on or make changes to this bug.