qemu -drive boot=on flag causes boot to hang.

I wrote a little script that should have solved my problems, however libvirt has other ideas.

http://pastebin.com/HgwtQ3iL
#!/bin/bash
out_args=( )
while (( $# ))
 do if [[ "$1" = "-drive" ]]
  then out_args+=( "$1" "$(<<<"$2" sed \
    -e s/,boot=on//g \
    -e s/boot=on,//g \
    -e s/boot=on//g \
   )" )
  shift 2
  else out_args+=( "$1" )
  shift
  fi
 done
exec "${0}-original" "${out_args[@]}"

http://pastebin.com/7SKxnJGV
Some strace output, the exec on line 15 fails with a permission problem.

(04:12:14 PM) cheako: operation="exec" pid=24359 parent=1 profile="libvirt-02e3d7e8-79e5-6dc3-2954-d43fe1130cdf" requested_mask="x::" denied_mask="x::" fsuid=0 ouid=0 name="/usr/bin/qemu-original"
(04:12:25 PM) cheako: operation="mknod" pid=24361 parent=24360 profile="libvirt-02e3d7e8-79e5-6dc3-2954-d43fe1130cdf" requested_mask="c::" denied_mask="c::" fsuid=0 ouid=0 name="/tmp/sh-thd-1276031548"
(04:12:39 PM) cheako: operation="open" pid=24359 parent=1 profile="libvirt-02e3d7e8-79e5-6dc3-2954-d43fe1130cdf" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/usr/bin/qemu-original"

I can't see reference to boot=on as a valid -drive option in qemu manpage... So that would be a libvirt bug ?
Your workaround fails due to apparmor protections around libvirt profiles.

FWIW, regarding the flag itself:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/19242

Still it works for me on x86_64 (where /usr/bin/qemu-original isn't
used). Is it worth updating the apparmor profile?

Mike, to libvirt your wrapper script is a new emulator and you must add a rule or rules for it in /etc/apparmor.d/abstractions/libvirt-qemu.

However, looking at the CurrentDmesg.txt file attached to this bug, there is nothing to indicate the original problem is an apparmor issue.

This bug is about qemu's option, if it's not a bug in qemu then this is a bug in libvirt for using this option. As for the selinux and apparmor issues these are bugs in my solution and have nothing to do with the bug being reported, but instead are related to one of it's /incomplete/ solutions.

That was simple add the following to the apparmor file:
  /usr/bin/qemu-original rmix,
  /bin/sed rmix,
  /tmp/sh-thd-* rw,

Also the dmsg statements that apparmor makes are not recognized by the SELinux ppl, they should all indicate from whence they hail.

The BUG here in qemu is that it starts, but then hangs!

> I can't see reference to boot=on as a valid -drive option in qemu manpage...

It's valid. It's used to tell qemu's extboot option rom to boot from the given device. It's the only way to boot from e.g. virtio devices (since they are not handled by the BIOS in qemu).

After reading the posted email thread, I've come to the conclusion that the -boot argument is missdocumented/missleading. In actuality it's "c" parameter is more like the "boot from first or selected hard disk" and "d" would be "boot from first or selected cdrom".

I think it would be best to remove this parameter, perhaps replacing it with a parameter to force a particular behavior(like the option to what format a block device is in). The boot sequence should attempt a cdrom boot, since this would fail quickly I'd imagine if the image was not an iso. Then booting the device like a hard disk or crash trying.

I made a change to my script.

#!/bin/bash
out_args=( )
while (( $# ))
 do if [[ "$1" = "-drive" ]]
  then out_args+=( "$1" "$(<<<"$2" sed \
    -e s/,boot=on//g \
    -e s/boot=on,//g \
    -e s/boot=on//g \
   )" )
  shift 2
  else out_args+=( "$1" )
  shift
  fi
 done
exec -a "$0" "${0}-original" "${out_args[@]}"

Now I see the true bug here. I setup WindowsXP to use the virtio block driver and now as predicted I can't boot from it. After removing the wrapper script it seams that GRUB hangs during boot.

Could there be a problem with the int13h driver?

After doing some digging I've made the assumption that this is a missing feature of the BIOS(seabios). I've build the latest code from GIT and am getting the same result. Using KVM this is working, can that be used to correct QEMU?

Hmm, wait there are two bugs here. I'm not sure if I can help get either of them fixed.

1. There is a bug in QEMU(perhaps related to the same bug in seabios) where when using "-boot a" and the "-drive" flag "boot=on" the system fails to boot. However removing the "boot=on" flag corrects this and there is a script above and minor edits to apparmor to correct for this.

2. Seabios lacks support for virtio-blk devices, or the same bug as above is interfering with the boot. To boot from virtio-blk one needs to use the "boot=on" flag.

Fails to boot is described above, however a recap here would be nice. The boot process hangs(idle for ever) during the BIOS and/or MBR stage of the boot.

SF bug 1977971 talks about boot from iso image and considered not a bug (according to comment 1)

ilia,
  What SF project, a link would be nice. The current link is kinda fun it links to that number "locally".

I have this working at home under KVM, it's the software emulator that this is broken on.

http://sourceforge.net/tracker/index.php?func=detail&aid=1977971&group_id=180599&atid=893831
This is also something to keep in mind, with or w/o "-boot c" it's the same.

The commit c0897e0cb94e83ec1098867b81870e4f51f225b9 in qemu-kvm
will fix this. Unfortunately the patch is not a simple one to cherry-pick. The
0.13.0 qemu-kvm release should be out soon, and should include this fix.
We will update the maverick qemu package to this release when it comes out.

Just to be clear the bug was reported while using GRUB, not the Windows XP loader. Grub did not start, so the config entry for XP shouldn't be an issue.

Though I can see where the BIOS would need to have the drive attached(and fully detected) if it's going to boot to it.

Mike - thanks, yes, that's also the bug I'm seeing - using a debian VM with
qemu (--no-kvm) inside a maverick kvm VM. Not at all a windows issue.

Note that installing qemu from git fixes the issue for me. When 0.13.0 with this fix
is released and packaged I'll drop a note here to ask for confirmation that it fixes
your bug.

thanks,
-serge

Milestoning in Ubuntu is used by the release management in conjunction with "Target to release" maverick, to identify milestone release blockers... I'm not sure this one should be considered a blocker. If you just intend to fix it by alpha3, you don't need to milestone it.

I needed to add "media=disk" option also to boot Windows XP properly on my Intel Atom D510 based system (Linux 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 x86_64 GNU/Linux). So the Mike`s script for me is:

#!/bin/bash

out_args=( )
while (( $# ))
 do if [[ "$1" = "-drive" ]]
  then out_args+=( "$1" "$(<<<"$2" sed \
    -e s/,boot=on/,media=disk/g \
    -e s/boot=on,/media=disk,/g \
    -e s/boot=on/media=disk/g \
   )" )
  shift 2
  else out_args+=( "$1" )
  shift
  fi
 done
exec -a "$0" "${0}-original" "${out_args[@]}"

It looks like this fix should be in v0.12.5 which is now packaged in maverick.

(Marked as invalid against libvirt since it was purely a qemu bug)