** Changed in: qemu-kvm
Assignee: Serge Hallyn (serge-hallyn) = (unassigned)
** Changed in: libvirt (Ubuntu)
Assignee: Serge Hallyn (serge-hallyn) = (unassigned)
** Changed in: qemu-kvm
Status: Fix Committed = Fix Released
** Changed in: qemu-kvm
Assignee: (unassigned) =
It looks like this fix should be in v0.12.5 which is now packaged in
maverick.
** Changed in: qemu-kvm
Status: Confirmed = Fix Committed
** Changed in: libvirt (Ubuntu)
Status: Triaged = Fix Committed
** Changed in: libvirt
Status: New = Fix Committed
--
qemu -drive
(Marked as invalid against libvirt since it was purely a qemu bug)
** Changed in: libvirt (Ubuntu)
Status: Fix Committed = Invalid
** Changed in: libvirt
Status: Fix Committed = Invalid
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You
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
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.
** Changed in: libvirt
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.
--
qemu -drive boot=on
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.
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a member
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
** Changed in: libvirt (Ubuntu)
Milestone: None = maverick-alpha-3
--
qemu -drive boot=on
** Changed in: qemu-kvm
Assignee: (unassigned) = Serge Hallyn (serge-hallyn)
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
SF bug 1977971 talks about boot from iso image and considered not a bug
(according to comment 1)
** Changed in: libvirt
Importance: Unknown = Undecided
** Changed in: libvirt
Status: Unknown = New
** Changed in: libvirt
Remote watch: SourceForge.net Tracker #1977971 = None
--
qemu
ilia,
What SF project, a link would be nice. The current link is kinda fun it
links to that number locally.
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a member of Ubuntu
Server Team, which is
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=detailaid=1977971group_id=180599atid=893831
This is also something to keep in mind, with or w/o -boot c it's the same.
--
qemu -drive boot=on flag causes boot
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?
--
qemu -drive boot=on flag causes boot to hang.
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.
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a
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?
--
qemu -drive boot=on flag causes boot to hang.
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
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
** Tags removed: apparmor
--
qemu -drive boot=on flag causes boot to hang.
https://bugs.launchpad.net/bugs/591423
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
--
Ubuntu-server-bugs mailing list
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.
** Package changed: qemu-kvm (Ubuntu) = libvirt (Ubuntu)
** Changed in: libvirt (Ubuntu)
Importance:
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?
--
qemu -drive boot=on flag causes boot to hang.
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.
--
qemu -drive
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.
--
qemu -drive boot=on flag causes boot
The BUG here in qemu is that it starts, but then hangs!
** Bug watch added: SourceForge.net Tracker #1977971
http://sourceforge.net/support/tracker.php?aid=1977971
** Also affects: libvirt via
http://sourceforge.net/support/tracker.php?aid=1977971
Importance: Unknown
Status:
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).
--
qemu -drive boot=on flag
** Attachment added: BootDmesg.txt
http://launchpadlibrarian.net/49966398/BootDmesg.txt
** Attachment added: CurrentDmesg.txt
http://launchpadlibrarian.net/49966399/CurrentDmesg.txt
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/49966400/Dependencies.txt
**
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 \
(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
29 matches
Mail list logo
