Ubuntu
kvm package

unable to boot linux vm's that are not Debian derived.

Bug #220463 reported by Jayson Rowe
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KVM
Unknown
Unknown
Fedora
Fix Released
Low
kvm (Ubuntu)
Invalid
Medium
Unassigned
Declined for Intrepid by Dustin Kirkland 
libvirt (Ubuntu)
Fix Released
Undecided
Unassigned
Declined for Intrepid by Dustin Kirkland 

Bug Description

Binary package hint: virt-manager

I am unable to start any Linux Virtual Machine that is not of Debian decent. I have tried Ubuntu, Debian Etch, Debian Lenny, Parsix, Elive, Mepis and Fluxbuntu. All these distros of Debian heritage run fine. Anything else gives the error: "Attempted DOS System Call" on boot-up. The Fedora Live-CD will not boot - gives that error from the start. I can install Foresight Linux, however I get the boot after installation has completed and the virtual machine is rebooted. I have attached screenshots. Please let me know any additional information you might need. I'm reporting this as a virt-manager error rather than a kvm error because I can start the virtual machines from the command line w/ kvm...the problem only exists when using virt-manager.

jayson@jlr:~$ uname -a
Linux jlr 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

jayson@jlr:~$ apt-cache policy virt-manager
virt-manager:
  Installed: 0.5.3-0ubuntu8
  Candidate: 0.5.3-0ubuntu8
  Version table:
 *** 0.5.3-0ubuntu8 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
Jayson Rowe (jayson.rowe) wrote :
Revision history for this message
Jayson Rowe (jayson.rowe) wrote :
Revision history for this message
Soren Hansen (soren) wrote :

Erk..

I think this is an extboot problem. I can run those CD's just fine with -cdrom path/to/the/iso, but with -drive file=/path/to/the/iso,if=ide,media=cdrom,boot=on it fails.

Revision history for this message
ivom (ivo-maljevic) wrote :

Among so many other problems with this tool I ran into this same problem. The workaround that worked for me:

- close virt-manager and instead run the kvm on the .img file from the command line untill you install your OS (eg., live CD, ISO, etc. )
- One you do this, your HD will be bootable and virt-manager will work.

Of course, it would be better if there was a real fix.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Changing to virt-manager, as this works for me from the command line, per Soren's instructions, not so much from virt-manager GUI.

:-Dustin

Changed in kvm:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'm actually getting this same error message when trying to boot Debian mini.iso's for Lenny and Sid, both i386 and amd64.

:-Dustin

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'm elevating the importance from Wishlist to Medium. This is a rather annoying issue, and significantly limits virt-manager's usage on Ubuntu.

:-Dustin

Changed in virt-manager:
importance: Wishlist → Medium
Revision history for this message
Soren Hansen (soren) wrote :

It's a kvm (extboot, actually) problem.

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

This also might be a bug in the vgabios package. See this bug in the Redhat bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=324561

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

After more investigation, it seems the bug is in neither with kvm nor vgabios. The problem seems to be with the way libvirt is invoking kvm/qemu.

Trying to install Fedora 9 onto a VM using virt-install results in the "Attempted DOS System Call" error, but I can manually create the VM without virt-install and the installer works fine.

Manual Steps:

1. I created the disk image:

  qemu-img create fedora.img 2G

2. I booted the ISO using kvm directly:

  kvm -cdrom Fedora-9-i386-disc1.iso -boot d fedora.img

In case the problem was with virt-install and not libvirt, I tried modifying the XML defining my fedora VM manually so it booting from the ISO... and again, same "Attempted DOS System Call" error, which again suggest the bug is in libvirt.

The sf bug #1977971 regarding kvm makes it clear that this is not really a bug but an issue of incorrect invocation. Perhaps a workaround will be added to kvm, but libvirt should be fixed to invoke it correctly.

Revision history for this message
In , Andy (andy-redhat-bugs) wrote :

Description of problem:

When installing fedora 9 64bit under KVM, the VM is created and the console
opens, and loads from the DVD, but at the boot: prompt the message "attempted
DOS system call" occurs.

If I select QEMU instead of KVM as the hypervisor, the installation does
continue past the boot: prompt.

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

libvirt.x86_64 0.4.3-1.fc10 installed
libvirt-python.x86_64 0.4.3-1.fc10 installed
python-virtinst.noarch 0.300.3-7.fc9 installed
virt-manager.x86_64 0.5.4-4.fc9 installed

How reproducible:
100%

Steps to Reproduce:
1. create new VM
2. installation source /dev/sr0

Additional info:

N.B I had to install libvirt 0.4.3 from rawhide to work around problem with

libvirtError: virDomainCreateLinux() failed internal error Timed out while
reading monitor startup output

Revision history for this message
In , Jonathan (jonathan-redhat-bugs) wrote :

Created attachment 311221
Screenshot of issue.

Revision history for this message
In , Jonathan (jonathan-redhat-bugs) wrote :

/usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name f9testlvm -monitor pty -boot c
-drive file=/home/jon/f9testlvm.img,if=ide,index=0,boot=on -drive
file=/home/jon/Downloads/Fedora-9-x86_64-netinst.iso,if=ide,media=cdrom,index=2
-net nic,macaddr=00:16:3e:2e:7b:73,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

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Seen on f9 32bit.

Fails with libvirt-0.4.4-1.fc9.i386.rpm libvirt-python-0.4.4-1.fc9.i386.rpm

Reverting to libvirt-0.4.2-3.fc9.i386.rpm libvirt-python-0.4.2-3.fc9.i386.rpm
removes the problem

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

This is a KVM bug when using the -drive parameter

The following two commands should be identical:

# qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500

# qemu-kvm -drive
file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500

But the 2nd fails with 'Attempted DOS system call'. New libvirt uses the -drive
argument, hence why you see it the problem with newer libvirt.

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Upstream thread shows that boot=on doesn't work reliably with CDROMs

http://thread.gmane.org/gmane.comp.emulators.kvm.devel/19242

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Please try using this libvirt scratch build and tell me if CDROM booting works

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

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Oh, don't forget to do 'service libvirtd restart' after installing the scratch
RPM to make sure it uses the new code. NB this will terminate all active guests,
so you might want to shut them down cleanly before this.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Test packages seem to allow a CD/DVD boot.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

libvirt-0.4.4-2.fc9 has been submitted as an update for Fedora 9

Revision history for this message
In , Andy (andy-redhat-bugs) wrote :

(In reply to comment #6)

> Please try using this libvirt scratch build and tell me if CDROM booting works

This version of libvirt failed for me, though not with the "DOS system call" error.

Previously when I used the latest libvirt for f9, I got the error

"libvirtError: virDomainCreateLinux() failed internal error Timed out while
reading monitor startup output"

I was able to install libvirt.0.4.3-1.fc10 to work around this, after which I
discovered the "DOS system call" error

Now I have installed libvirt-0.4.4-2.fc9 I one again get the

"libvirtError: virDomainCreateLinux() failed internal error Timed out while
reading monitor startup output"

error, so it doesn't get far enough to attempt to boot from CD.

If I remember correctly the fix in libvirt.0.4.3-1.fc10 was related to something
overwriting file descriptors?

Revision history for this message
In , Cole (cole-redhat-bugs) wrote :

Is there a logfile at /var/log/libvirt/qemu/guestname.log?

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

One bug per ticket please. If you have another problem besides the 'attempted
DOS system call' issue we've already addressed here, please open a new BZ

Revision history for this message
In , Andy (andy-redhat-bugs) wrote :

(In reply to comment #12)

> One bug per ticket please.

Yes I will open a new ticket, the reason I hadn't opened one previously was
because I was hoping that once libvirt-0.4.3-x or later was available for f9, it
would include the fix I knew was already in rawhide ...

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

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

Revision history for this message
Anders Kaseorg (andersk) wrote :

Here’s a debdiff that adds a patch extracted from the libvirt-0.4.4-2.fc9 RPM <ftp://download.fedora.redhat.com/pub/fedora/linux/updates/testing/9/SRPMS/libvirt-0.4.4-2.fc9.src.rpm>. I just tested it and it indeed fixes this problem.

Revision history for this message
In , Andrew (andrew-redhat-bugs) wrote :

I'm still seeing this on x86_64 F9. The curious thing is that the
bodhi-generated comment (#9) mentions a version different than what I have and
what is referenced in Dan's koji link:

$ rpm -q libvirt
libvirt-0.4.4-1.fc9.x86_64

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

Right, this is fixed in libvirt-0.4.4-2.fc9. Most likely whatever mirror you
are using doesn't yet have this in updates or updates-testing (I can't remember
at the moment where it is). It might be best to point directly at the main
fedora site for this update, and then switch back to your local mirror.

Chris Lalancette

Revision history for this message
In , Andrew (andrew-redhat-bugs) wrote :

I don't think your update is in update or updates-testing but I installed
0.4.4-2 straight from koji and it now works. Thanks.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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

Revision history for this message
Kai Blin (kai.blin) wrote :

Any news on this one?

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'm marking this as Fix Released.

Previously, I could not boot Fedora or Debian install media, or virtual machines. I'm now able to boot and run both.

Please re-open with details, if this is still a problem for you.

Thanks,
:-Dustin

Changed in kvm:
status: Confirmed → Fix Released
Changed in libvirt:
status: New → Fix Released
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

This was actually a bug in libvirt, not kvm. Marking the kvm task 'Invalid'.

:-Dustin

Changed in kvm:
status: Fix Released → Invalid
Revision history for this message
laksdjfaasdf (laksdjfaasdf) wrote :

Is there any chance, that this patch will be backported to Ubuntu Hardy, too?

Revision history for this message
freakalad (freakalad) wrote :

Issue is still present, even after numerous updates & releases (discrepancies between KVM, libvirt & virt-manager seem to be getting more pronounced)
Hardy 64.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Declining for intrepid and hardy.

These issues should be fixed in the kvm-84 package that's available in hardy-backports and intrepid-backports. If this issue is still critical to you, please try those packages.

:-Dustin

Bug Watch Updater (bug-watch-updater)
Changed in fedora:
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.