Bug 579348

This procedure works for me:

- create WinXP ISO image from install disk
- mount the image in the host as CDROM
- set boot sequence to CDROM

VM will then try to boot from CDROM first. Skip "press any key to boot form CDROM" by NOT pressing any key, and it will continue to boot from the disk.

Unfortunately, you will need this bootable CDROM mounted if you want to boot VM at all. Hopefully, this issue will be soon resolved.

*** Bug 599224 has been marked as a duplicate of this bug. ***

Created attachment 421267 [details]
libvirtd logfile while installing windows xp

I attached the requested log file for my vm. Nothing special in there, i guess...

Just 2 notes:

I have tried out the above procedure, my vm indeed boots, but than hangs with a blue screen.
I also tried to install good old "Windows 98 SE", but this install media will not boot.

This win98 vm will exit with:

kvm: unhandled exit 80000021
kvm_run returned -22

I think you removed support for Win98 in this version, but maybe it will be helpfull.

best regards

I'm not sure if it's a libvirt or a KVM bug, but this thread is interesting: http://www.mail-archive.com/qemu-devel@nongnu.org/msg32988.html

Bruce Rogers wrote a KVM patch that fixes the problem, but I don't know if it's the right way to fix the bug...

> I've been able to determine that there is a CMOS byte which indicates to the
> BIOS what IDE drives should use translation. This gets handled correctly for
> the old way of specifying drives, but the same isn't done in the qdev storage
> device code.

This comment from the URL in the initial description strongly points to QEMU as
the source of the bug. It says that the old style '-drive' options work, but
the new '-drive + -device' style does not. This isn't libvirt's fault, because we're just following the recommended QEMU command line argument usage here.

Created attachment 430133 [details]
Odd character in the SeaBIOS string

I am running into the same or a similar problem with the current libvirt/QEMU packages from Debian 'testing' running a Windows 2003 R2 virtual machine. When booting via de CD-ROM as noted above the VM boots fine, when booting directly from disk (qcow2 image) it shows an odd character in the SeaBIOS string that isn't there when using the CD-ROM 'bypass' ... there should be a '5' instead of that odd circle thingie.

Hope this helps someone with more of a clue than me :)

Created attachment 430885 [details]
screenshot of error

Message I see right after it copies the files and starts it downward swing to reboot  and finish the initial setup.

I get the exact same problem as the reporter.

I seem to be having the same bug with a Windows 2000 guest. Install completes successfully, but then I get the "disk read error has occurred" message as described.

Trying to boot from a CD, qemu died leaving this in the log:
qemu: hardware error: level sensitive irq not supported
CPU #0:
EAX=0000007d EBX=00000000 ECX=f710ffff EDX=00010020
ESI=00000086 EDI=00000250 EBP=0000f438 ESP=0000f442
EIP=0000665b EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =0000 00000000 0000ffff 00009b0f
SS =0000 00000000 0000ffff 00009300
DS =07c0 00007c00 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000f7a30 00000037
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
DR6=ffff0ff0 DR7=00000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
(remaining registers all 0)

I am using qemu-system-x86-0.12.3-8.fc13.x86_64. This machine is not kvm capable. Note that the above occurs whether or not the mounted ISO is bootable.

An image I created previously in F11 works when I run qemu directly. Since I use -hda with qemu, the -drive/-device issue may be in play here.

> Note that the above occurs whether or not the mounted ISO is bootable.

My bad, the ISO I thought wasn't bootable, is. When a non-bootable ISO is used, I just get the same error as booting straight from the HD image.

I have found this same problem.   I'm installing using a slightly different situation -- I'm restoring a WinXP/Win2k3 backup that was made with fsarchiver -- but essentially I run across the same issue namely that boot fails when mbr tries to boot the first partition.  In my case I use install-mbr from the mbr package but have also tried to install the windows mbr from the boot cd without success.

After much trial and error and a comparison of a previously successful installations (using older version) and current, it seems that the ntfs filesystem made while booted into a kvm virt does not correctly set the offset value of the boot partition found and thus the ntfs will not load properly after the mbr hands off.

For example, a single partition install of XP or Win2k3 will have a partition that begins at sector 63.  To boot the NTFS file system would record this offset at 0x7E1C.  In previous versions this would result in the value '3F' but in the current version it results in '00'.

In this single partition example, after install using a hexeditor on the raw disk to change the value of 0x7E1C to '3F' will allow the boot to work normally.

Seems like there has been a change with kvm that prevents the ntfs filesystem from being created successfully.  It still seems valid for data but the BIOS parameter block of the NTFS file system is not being created successfully.

My steps to reproduce were as follows:
1. make backup
 fsarchiver savefs win.fsa /dev/sda1
2. create disk
 lvcreate -L10GB -n win vg
3. partition
  fdisk /dev/vg/win
4. mount to loop, restore, detach
 kpartx -av /dev/vg/win
 fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1
 kpartx -dv /dev/loop0
5. install mbr
 install-mbr /dev/vg/win

at this point the system wil noot boot -- hangs after MBR.  However, if you change 0x7E1C to '3F', the resulting image will boot fine:

6. after hexedit, boot, success
 kvm -m 1024 -hda /dev/vg/win

I have had a Windows 7 32-bit guest for many months now.  I haven't tried to start it in a few weeks.  Using virt-manager... I try to start it and I get the following error:

- - - - -
Booting from Hard Disk...
Boot failed: not a bootable disk

No bootable device.
- - - - - 

I went into virt-manager's config section for the VM and made sure that only the hard disk was selected for boot.  Then I removed that.  Then I added it back... just in case but I still get the same error.

Luckily I had a backup of the VM disk image... that is known good... because the VM has booted many times after making that backup.  I restored the backup image and tried booting that (moved the suspected bad .img out of the way and put the backup in its place and then restarted libvirtd)... and I still get the same error.

It appears there is something about the disk img MBR or header... that KVM isn't liking... and has decided that it isn't a bootable device.  I'll attached the .xml config for the VM.

Created attachment 435349 [details]
XML config for my Windows 7 VM that has a "No bootable device." error

XML config for my Windows 7 VM that has a "No bootable device." error

I have isolated it a little... and come up with a bootable (although networking is broken) command line:

The command line that virt-manager was issuing was:

/usr/bin/qemu-kvm -S -M pc-0.11 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 \
-name Windows7 -uuid 7fef71c2-185a-9924-0439-bd5b85decf3e -nodefaults \
-chardev socket,id=monitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait \
-mon chardev=monitor,mode=readline -rtc base=localtime -boot c \
-drive file=/vm/Windows7Pro.img,if=none,id=drive-ide0-0-0,boot=on,format=raw \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
-drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw \
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \
-device rtl8139,vlan=0,id=net0,mac=52:54:00:0e:75:2e,bus=pci.0,addr=0x4 \
-net tap,fd=40,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 \
-usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus \
-device ES1370,id=sound0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3

That would not boot from the command line. To get it to work I stripped off some of the -drive options as well as altered the -net options.  The following command booted the machine... although like I said, networking was broken.

/usr/bin/qemu-kvm -M pc-0.11 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 \
-name Windows7 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait \
-mon chardev=monitor,mode=readline \
-rtc base=localtime -boot c -drive file=/vm/Windows7Pro.img \
-device rtl8139,vlan=0,id=net0,mac=52:54:00:0e:75:2e,bus=pci.0,addr=0x4 \
-net user \
-chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 \
-sdl -vga cirrus -device ES1370,id=sound0,bus=pci.0,addr=0x5 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3

Something about the -drive and/or the -net options that virt-manager was passing caused the the disk image to appear to be unbootable.

Just wanted to mention that my Fedora 13 x86_64 install is completely up-to-date and I have the following packages installed:

libvirt-0.8.2-1.fc13.x86_64
libvirt-client-0.8.2-1.fc13.x86_64
libvirt-python-0.8.2-1.fc13.x86_64
python-virtinst-0.500.3-2.fc13.noarch
python-virtkey-0.50-6.fc12.x86_64
qemu-kvm-0.12.3-8.fc13.x86_64
seabios-bin-0.5.1-3.fc13.noarch
virt-manager-0.8.4-1.fc13.noarch
virt-viewer-0.2.1-1.fc13.x86_64

Nevermind.

nirik in the #fedora IRC channel pointed out to me the updated libvirt package details (although not included in the rpm changelog) for the recent libvirt update.  Info here:

https://admin.fedoraproject.org/updates/libvirt-0.8.2-1.fc13

Sure enough according to qemu-img info my Windows7.img was qcow2 format.  To fix it I edited the qemu.conf to turn probing back on and edited the Windows7.xml config and changed the disk format from "raw" to "qcow2".  All of those details are mentioned in the updated libvirt update info linked above.

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

According to the upstream qemu bug at https://bugs.launchpad.net/bugs/586175
the debian qemu has a fix for this. Is that gonna get to fedora sometime soon?
I was just trying to install XP from scratch to test something and ran into
this same problem on a fully updated fedora 13 64 bit system.

My impression is that the problem is the disk image itself being busted.
I think I'll trying copying an old XP image I have and see if I can just
overwrite it to get a new XP.

Nope, even using a copy of an existing (and working) disk image and re-installing
on top of it still produces a new XP that can only boot from CD.

OK, I got it to boot by following some of the hexedit advice in
the various links. It was slightly complicated by the fact
that my image is a qcow2 file, so rather than try to deal with it
directly, I simply added it as a 2nd disk in a linux virtual machine
then ran hexedit on /dev/vdb inside that KVM.

I poked around and compared various fields that were mentioned in
different bugs, and the one that made the disk image bootable for
me was changing 0x7E1A to 0xFF.

You should be able to use ntfsreloc to fixup the Windows boot sector without having to resort to hexediting it...

http://www.linux-ntfs.org/doku.php?id=contrib:ntfsreloc

Tim.

I hope this gets fixed soon. There are so many possible solutions all over the web but none of them work consistently. 

Same problem:

Booting from Hard Disk...

A disk read error occurred

This is a WinXP Professional x86 VM

Running: fedora 13 2.6.33.8-149.fc13.x86_64

qemu-common-0.12.5-1.fc13.x86_64
qemu-system-sh4-0.12.5-1.fc13.x86_64
qemu-system-sparc-0.12.5-1.fc13.x86_64
gpxe-roms-qemu-1.0.1-1.fc13.noarch
qemu-system-arm-0.12.5-1.fc13.x86_64
qemu-system-mips-0.12.5-1.fc13.x86_64
qemu-system-x86-0.12.5-1.fc13.x86_64
qemu-kvm-0.12.5-1.fc13.x86_64
qemu-system-m68k-0.12.5-1.fc13.x86_64
qemu-user-0.12.5-1.fc13.x86_64
qemu-img-0.12.5-1.fc13.x86_64
qemu-system-cris-0.12.5-1.fc13.x86_64
qemu-system-ppc-0.12.5-1.fc13.x86_64
qemu-0.12.5-1.fc13.x86_64

Created attachment 441329 [details]
Attempted backport to qemu 0.12 stable

Markus, this winxp startup bug is still present in F13 and a lot of users seem to be hitting it. I know you did the upstream fix:

http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c0897e0cb94e83ec1098867b81870e4f51f225b9

but it doesn't backport cleanly to 0.12 stable. I attempted a backport (the attached patch), but besides getting it to compile and not immediately blow up, it didn't seem to resolve the situation, understandable since I have little understanding of the affected code. Any hints for fixing this properly?

*** Bug 611065 has been marked as a duplicate of this bug. ***

I am looking at back porting the patch for F13, but this is listed as an F14 bug.  F14 is using the 0.13 tree now which should not have the issue.  Can anyone verify that F14 (or F13 virt-preview) works for them, and we can relabel this bug as F13?

Using F13 virt-preview I get "VNC connection to hypervisor host got refused or discinnected!" as soon as windows setup finishes formatting the partition. After reboot I get (to be expected):

---
Booting from Hard Disk...
Error loading operating system_
---

I have the same exact problem trying to install Windows 2000 Pro on a 64 bit Fedora-13 system. After the first phase of the install I get a boot device failure.

I also found that importing the ".img" file for a Windows XP Pro installation done on a 32 bit Fedora-11 system works. It boots up just fine on the same machine, the 64 bit Fedora-13 system, where I have the problem with installing Windows 2000 Pro from a bootable iso file. Looks like if the VM boot disk doesn't get screwed up things work.

Created attachment 445802 [details]
VM file from booting Fedora-11 system

This is the Windows XP pro VM xml file from a booting Fedora-11 system using 1 cpu

Created attachment 445803 [details]
Booting VM xml file for Fedora-13

This is the same xmf generated from a VM ".img" imported from a booting Windows XP Pro installation, on a 32 bit Fedora-11, in to a 64 bit Fedora-13 system. The memory and number of cpu's was increased after the VM booted on the target Fedora-13 system several times without a problem.

I've attached copies of the two xml files generated by first a 32 Fedora-11 installtion of Windows XP Pro. Then the ".img" file was copied to a 64 bit Fedora-13 system an imported user virt-manager.

The imported "img" VM seems to fuction just as well in Fedora-13 as it did in Fedora-11, including networking, since I can do the Windows updates through IE7 right from the Microsoft site.

Description of problem:

I an having the same issue... 

> I can do the first part of the install for WinXP using
> virt-manager, but on reboot I keep getting a disk error

booting from hard disk...

a disk read error ocurred
press ctrl-alt-del to restart


# virt-manager

* Click on "create a new virtual machine"
* Set "name" to WinTST
* Choose "local install media..."
* Set "OS Type" to "windows" and "Version" to "Microsoft Windows XP (X86)"
* Select "use iso image..." ---> click "browse" ---> click "browse local" ---> select install media
* Set "memory" to 512 and "cpus" to 1 
* Choose "Select managed or other existing storage" ---> click "browse"
* Select "foo-pool" storage pool ---> click "new volume" 
* Create a volume "wintst_disk0.img" format "raw" with max capacity set to 8000 mb ---> finish ---> select volume and click "choose volume"
* Choose a custom private network for the vm
* Virt Type is kvm
* Architecture is x86_64 ---> click "finish"

* The vm-guest boots, the install process starts...  ...setup is copying files, bla bla bla... 
  and then it needs to reboot to finish installing

* guest reboots and it says:
 
booting from hard disk...

a disk read error ocurred
press ctrl-alt-del to restart


WORKAROUND:
-----------

-) force power off the vm
-) click "show virtual hardware deails" ---> select "boot options"
-) click and select "cdrom" ---> press "up arrow" and move it to the top of the list. 
-) click and unselect "hard disk" ---> click "apply"
-) power on the vm
-) it boots from cdrom (the install media), wait for the timeout to expirte, then it boots from hard disk. 
-) Wait for the instalation process to finalize. The install (bootable) cd must be allways be present. 
-) there is no way to boot the guest from the hard disk image directly .... :-(


# yum list installed '*virt*'
Loaded plugins: presto, refresh-packagekit
Installed Packages
libvirt.x86_64                                                0.8.2-1.fc13                                      @updates
libvirt-client.x86_64                                         0.8.2-1.fc13                                      @updates
libvirt-python.x86_64                                         0.8.2-1.fc13                                      @updates
python-virtinst.noarch                                        0.500.4-1.fc13                                    @updates
virt-manager.noarch                                           0.8.5-1.fc13                                      @updates
virt-viewer.x86_64                                            0.2.1-1.fc13                                      @fedora 
virtuoso-opensource.x86_64                                    6.1.2-1.fc13                                      @updates

# yum list installed '*qemu*'
Loaded plugins: presto, refresh-packagekit
Installed Packages
gpxe-roms-qemu.noarch                                      1.0.1-1.fc13                                         @updates
qemu-common.x86_64                                         2:0.12.5-1.fc13                                      @updates
qemu-img.x86_64                                            2:0.12.5-1.fc13                                      @updates
qemu-kvm.x86_64                                            2:0.12.5-1.fc13                                      @updates
qemu-system-x86.x86_64                                     2:0.12.5-1.fc13                                      @updates

# uname -a
Linux xxxxxxxxx.xxxx 2.6.34.6-47.fc13.x86_64 #1 SMP Fri Aug 27 08:56:01 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

The original patch from Markus Armbruster (http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c0897e0cb94e83ec1098867b81870e4f51f225b9) was backported to 0.12.5 in Debian. See here: http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=blob;f=debian/patches/upstream-stable02-fix-CMOS-info-for-drives-defined-with--device.diff;h=24cd5598a722fe79bdcc245f664402fd6e2e0339;hb=HEAD

*** Bug 611725 has been marked as a duplicate of this bug. ***

I have loaded Fedora 14 beta and updated all. I had all the problems listed in F13

I can now only create VM, format disk (xp install). At the end of the format the manager drops back to "Guest not Running" and that the end of it.

I am running on a Dell Optiplex 620 Pentium 4 so no VT only qemu

I have logged this here as it would seem F14 versions will need some testing. If any one wants me to try anything let me know

Mike

qemu-0.13.0-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/qemu-0.13.0-1.fc14

qemu-0.13.0-1.fc14 has been pushed to the Fedora 14 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 update qemu'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/qemu-0.13.0-1.fc14

Yep can now install from .iso. BUT using Virt Manager it reports Connection to Hypervisor lost or refused. Needed to do a complete restart of system but was then able to continue install

Works for me, installed windows xp pro as guest without problems using f14 as host.

In addition to comment 38 i should have said

It does install and run.

its just strange behaviour when XP want to reboot during the install. It drops the conection to the Virtual Manager and cant or does not re-establish it. Is this normal ?

The strange behaviour above I think can be attributed to Bug 628721
	
The upstream fix quoted in Bug 628721
	

 also does not appear to fix the problem

The workaround worked on my fedora 12

qemu-0.13.0-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Where are the Fedora-13 updated files? I got and email from a Justin Forbes on 10/12 that read in part as ...

---------------------------------------------------------------------------
It will be in the next update for F13.  I mistakinely thought it had made
the 0.12.5 stable release upstream, so did not apply seperately.  In the
meantime, there is a workaround, or you can use the F14 qemu from
virt-preview.

Justin
----------------------------------------------------------------------------

As far as I can tell it still hasn't made it to the updates. I've done several updates to my system including a new kernal just a few days ago, but no fix was seen for this bug yet as he mentioned. Is this bug going to be ignored so anybody that wants a fix will be forced to upgrade to Fedora-14, where I assume, or hope, its fixed?

Reopening against F13. Comment #33 links to a possible backported fix.

I tried re-test the bug, and found that it is not currently fixed in F13.

And while testing this issue (due to this an other issues, i do not use libvirt on this machine) libvirt caused the most ugly kernel KraSh i have seen (i do experience xorg crashes due to other bugs in xorg/nouveau [reported] related). Once i am sure that i can reproduce it i will open a proper bugreport.

Again speaking on this bugreport issue, will it be included in F13? if not, please tell so i prepare for the update to F14.

Does this work now as haven't seen reports on this lately?

I no longer update F13, now using F15 (in another partition) which works great.

The last time i updated F13, i think (i need to recheck, maybe during the week) that 
it was fixed. The problem is that it BROKE the affected VMs, so i downgraded and
stopped updating until F15 is released. I will try to update again and check.

I updated F13 and re-tested

* For newly installed winxp guests (type windows/winxp, default kvm/x86_64), the issue seems fixed now. These can boot from hard disk now.

* Already installed guest must keep using the 'boot via winxp cdrom' workaround, since these guests cannot boot from hard disk.

The breakage i experienced the other time is now gone.

libvirt.x86_64                        0.8.2-6.fc13                    @updates
libvirt-client.x86_64                 0.8.2-6.fc13                    @updates
libvirt-python.x86_64                 0.8.2-6.fc13                    @updates
python-virtinst.noarch                0.500.4-2.fc13                  @updates
virt-manager.noarch                   0.8.5-1.fc13                    @updates
virt-viewer.x86_64                    0.2.1-1.fc13                    @fedora 
virtuoso-opensource.x86_64            6.1.2-1.fc13                    @updates

- I don't see this issues any longer on new installs.
- On old installs that were broken or ones I was migrating during this period using 'ntfsreloc' as suggested above to fix the ntfs partition corrected the problem and allowed booting from disk.

I cannot downgrade :-( 

both python and qemu-kvm uses more that 100% cpu each one. idle xp guest uses 60% cpu.
xp guest segfault qemu-kvm afer some minutes of high cpu usage, and display freezes very often.

Migrating to my F15 beta is not an option due to 'similar' performance problems recently introduced there, also linux guests crashes there due to high cpu usage.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I no longer have F13 installed, moved on to F15.

The last time i tried with F13, it worked. (But i got another big problem)

The reason to downgrade in F13 (i ended downgrading before switching to F15) was a performance problem. Downgrading mitigated it enough to be usable.

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.