Zhang, Xiantao wrote:
Christian Ehrhardt wrote:
<[...]
@@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
addr, uint8_t *buf, phys_ram_dirty[addr1 >>
TARGET_PAGE_BITS] |= (0xff &
~CODE_DIRTY_FLA
Hollis Blanchard wrote:
On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote:
Hollis Blanchard wrote:
A comment to explain why the icache needs flushing only in the KVM
case
would be useful. Other than that I'm fine with it.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]
S="$LDFLAGS -pthread" before
doing configure&make.
Maybe it's worth a try if this helps your linker to find the pthread functions.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
latest cvs snapshot or on this list)?
--- thread from kvm-ppc-devel ---
Jimi Xenidis wrote:
On Jan 11, 2008, at 10:04 AM, Hollis Blanchard wrote:
On Fri, 2008-01-11 at 14:14 +0100, Christian Ehrhardt wrote:
Hi,
maybe its an issue of my build environment only, but when I compile
kvm-userspace for
Salil Bijur wrote:
On Jan 16, 2008 5:59 PM, Christian Ehrhardt <[EMAIL PROTECTED]> wrote:
Salil Bijur wrote:
On Jan 16, 2008 4:48 PM, Mulyadi Santosa <[EMAIL PROTECTED]> wrote:
Hi
On Jan 16, 2008 5:20 PM, Salil Bijur <[EMAIL PROTECTED]> wrote:
Hello,
I've be
> @cpaelzer, if you have any suggestions for specific tests/configurations
> that might be good to test the specific code changed here, please let me
> know.
I have ran the few test that would cover that area in the past on PPAs already.
Unfortunately this is a very specific path and I don't have
> I'd bet on this being the one fixed by
> 2bbadb08ce272d65e1f78621002008b07d1e0f03
But wasn't the breakage this fixes only added in qemu 4.0?
He reports his change is from qemu 2.10 to 2.11.
Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has
something backported that makes the
> I'd bet on this being the one fixed by
> 2bbadb08ce272d65e1f78621002008b07d1e0f03
But wasn't the breakage this fixes only added in qemu 4.0?
He reports his change is from qemu 2.10 to 2.11.
Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has
something backported that makes the
I forked that new discussion into
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497
Please follow there and leave this bug here to the originally reported error
signature.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
ht
** Attachment added: "strace of the hanging qemu-img"
https://bugs.launchpad.net/qemu/+bug/1848556/+attachment/5298128/+files/qemu-img-hangs.strace
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/18
Hi Rod,
I did try to recreate with the qemu version that you have.
$ apt install apache2 qemu-system-x86
$ qemu-img create -f qcow2 /var/www/html/test.img 1G
# local
$ qemu-img check test.img
No errors were found on the image.
# remote
$ qemu-img check http://localhost:80/test.img
The stuck poll is at:
#0 0x7fafb935ad26 in __GI_ppoll (fds=0x560dba615670, nfds=1,
timeout=, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at
../sysdeps/unix/sysv/linux/ppoll.c:39
#1 0x560db89550b9 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits
Quick checks:
- does not depend on the exact image, e.g.
https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-amd64.img or
https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2
hang as well
- the former qemu 3.1 bas
Since it seemed so easy, while bisecting I found that it hangs with
v4.0.0 and v3.1.0 from git and even v3.0.0.
Since the reported good version was 3.1 I began to wonder if I might have
overlooked something.
I wondered if it might be e.g. the apache version providing a different
behavior on http
Hi Max,
libcurl 7.65.3-1ubuntu3 and was >7.59 for several releases (more than a year at
least) - so there must be something else going on that this triggers now.
But never the less with the fix from [1] I can again get it to work
successfully.
I think I should backport that to our qemu 4.0 in Ub
** Description changed:
+ Ubuntu SRU Template:
+
+ [Impact]
+
+ * There is fallout due to changes in libcurl that affect qemu and might
+lead to a hang.
+
+ * Fix by backporting the upstream fix
+
+ [Test Case]
+
+ * If you have network just run
+$ qemu-img check http://10.193.37.
@Rod: Your self built issue seems like at config/make time there were
not all build deps available. I have put a test build in PPA [1], could
you give that one a try on your end as well?
[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1848556-qemu-
img-curl-hang-eoan
--
You received this
For me with the version from the PPA works fine on local as well as remote http
connections.
Thanks @Max for the fix.
@Rod:
Waiting for you to test and verify based on the PPA.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:/
This was tonight first accepted and then immediately rejected as it was
surpassed by a security fix.
=> Rebased and uploaded 1:4.0+dfsg-0ubuntu9.2 to eoan-unapproved again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs
Eoan - without fix -> hang
With fix:
qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
No errors were found on the image.
That is a long list of install commands Hans Peter, wouldn't dependencies just
take care of it as well?
Anyway, I installed the same set of packages and it works fine for me.
Which Ubuntu release are you on?
What machine are you on?
Any further configuration done to libvirt yet?
Maybe a list of a
That crash seems to be from sessioninstaller which is not related to
virt-manager.
But never the less from your log:
"ValueError: Namespace GtK not available"
But virt-manager could require the same.
In fact things are provided by gir1.2-gtk-3.0 and virt-manager has:
Depends: ... gir1.2-gtk-3.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838569
Title:
virtio-balloon change breaks post 4.0 upgrade
Status in QEMU
In regard to "similar bugs" it sounds more like [1] to me.
Which was around needing [2].
But just like the commit David mentioned is in 2.8 this one is in since
2.6 (and backported).
[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389
[2]:
https://git.qemu.org/?p=qemu.git;a=commit;h
FYI - Focal now contains 4.2 which might (or not) have the bits you need.
You most likely get further, but I can't give guarantees if enough of march=z13
is supported to work for a full Focal (not sure on vector instructions for
example) including all of userspace.
Marking it incomplete - if som
** Attachment added: "Serial log "as it was once working""
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327028/+files/working-guest-serial.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net
** Attachment added: "Guest XML "as it was once working""
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327027/+files/vm1-as-deployed-by-maas.xml
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
The one that currently is deployed is using the same "list network and hd"
which should not work.
It will boot network but should not internally fall back to disk.
10
11 hvm
12
Here are the interesting bits from the log:
1 LOADPARM=[]^M
2 Network boot device detected^M
3 ^M
I flipped
to
And JFH started it from the MAAS UI again.
Now things work (obviously as expected)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to
@sfeole - after initial deployment just do the change to your guest XMLs
you see in comment #27
@maas - as I said in comment #26 (and before) this needs coding in maas
to switch the XML content (or waiting a long time on IBM)
--
You received this bug notification because you are a member of qemu
The assumption from here was that this only appeared to be working due
to:
a) Deploy = netboot + reboot from disk = working
but at the same time
b) Start = netboot (fail) + no fallback = fail
To get that from Maas UI we stopped the guest (it went down as expected).
Then from Maas we said "powe
OR
Maas can boot from network (always) and if not deploying just issue a "reboot
from disk" command
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM ma
not have any background on this but stumbled over this and wondered,
is there any particular reason why this wasn't applied yet?
It seemed to fix a former mistake, was acked and then ... silence
> >
> > /* FP and SSE are always allowed regardless of XSAVE/XCR0. */
> > *ecx |= XSTATE_FP_MASK | XSTATE_SSE_MASK;
>
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
While the bugzilla case wasn't updated this landed in v8.7.0 via a series around
https://gitlab.com/libvirt/libvirt/-/commit/e6c29f09e5b75d7a8d79ae670407060446282c78
v9.0.0 of libvirt is in Ubuntu Lunar, due to that - from now on - one
can control the physical bit settings in a defined way through
From: Christian Ehrhardt
The virtiofsd currently crashes when used with glibc 2.35.
That is due to the rseq system call being added to every thread
creation [1][2].
[1]: https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/
[2]: https://sourceware.org/pipermail/libc-alpha/2022
uot;)
Reported-by: Christian Ehrhardt
Tested-by: Christian Ehrhardt
> This bug was detected when running the 'arm' emulator on an s390
> system. The s390 uses TCG_TARGET_EXTEND_ARGS which triggers code
> in tcg_gen_callN to extend 32 bit values to 64 bits; the incorrect
> sign
convoluted case an FYI to everyone involved
back then,
the fix seems to have caused a regression [1] in - as far as I've
found - an edge case.
[1]: https://gitlab.com/qemu-project/qemu/-/issues/1520
...
> Laszlo
>
>
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
From: Christian Ehrhardt
Some of the roms build with -march=i486 -m16 which is incompatible
with -fcf-protection. That in turn is can be set by default, for
example in Ubuntu [1].
That causes:
cc1: error: ‘-fcf-protection’ is not compatible with this target
This won't work on -march=i486
On Wed, Mar 23, 2022 at 11:54 AM Philippe Mathieu-Daudé
wrote:
>
> On 23/3/22 10:07, christian.ehrha...@canonical.com wrote:
> > From: Christian Ehrhardt
> >
> > Some of the roms build with -march=i486 -m16 which is incompatible
> > with -fcf-protection. That in
Hi,
sorry this has fallen through the cracks, but bug 1928075 made me re-discover
it and it is time finally to complete that.
** Tags added: server-next
** Description changed:
[Impact]
- * The current space reserved can be too small and we can end up
-with no space at all for BRK. It
SRU template updated, PPA rebuilt, Merge requests updated.
Also bundled another bug fix.
Waiting for MR review now.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working
** Changed in: qemu (Ubuntu Focal)
Status: Triaged => In Progress
** Changed in: qemu (Ubuntu Focal)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Uploaded to F-unapproved, waiting for the SRU team to accept it.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
Status
Focal
old
$ sudo apt install --reinstall qemu-user-static=1:4.2-3ubuntu6.18
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 21.3 MB of archives.
After this ope
On Wed, Mar 1, 2023 at 9:04 AM Laszlo Ersek wrote:
>
> Hello Christian,
>
> On 3/1/23 08:17, Christian Ehrhardt wrote:
> > On Thu, Jan 5, 2023 at 8:14 AM Laszlo Ersek wrote:
> >>
> >> On 1/4/23 13:35, Michael S. Tsirkin wrote:
> >>> On Wed, Jan
FYI the release of this is slowed down by the slow verification of bug
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1929926
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk(
Thank you Frank for that extra confirmation,
by now also all the blockers on the other bug fixed are good. I expect this to
be released as soon as the SRU Team is back from the Christmas shutdown.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscrib
@Thomas - there is a leftover task here and I've filed [1] for it in the new
tracker.
What is the right state to move this bug here into now?
[1]: https://gitlab.com/qemu-project/qemu/-/issues/137
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #137
https://gitlab.com/qemu-project/q
Allow enabling seccomp support on s390x if sufficient build
dependencies are provided.
Signed-off-by: Christian Ehrhardt
---
configure | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure b/configure
index 86f5214..5056ba9 100755
--- a/configure
+++ b/configure
@@ -1927,6 +1927,9
On Tue, Aug 15, 2017 at 3:07 PM, Fam Zheng wrote:
> v2: Don't leak blk->vmsh when BB is deleted before the callback is called.
> [Stefan]
> From stub functions, don't return g_malloc0(1) which is risky, return
> NULL.
> [Eric]
Thanks Fam Zheng and Kevin Wolf,
retesting on -rc3 clear
On Wed, Aug 23, 2017 at 8:53 AM, Christian Borntraeger <
borntrae...@de.ibm.com> wrote:
> KVM guests on s390 need a different page table layout than normal
> processes (2kb page table + 2kb page status extensions vs 2kb page table
> only). As of today this has to be enabled via the vm.allocate_pgs
On Wed, Aug 23, 2017 at 6:33 PM, Eric Blake wrote:
[...]
>
>
> nbd patches for 2017-08-23
>
> - Fam Zheng: 0/4 block: Fix non-shared storage migration
> - Stefan Hajnoczi: qemu-iotests: add 194 non-shared storage migration test
> - S
bugzilla/show_bug.cgi?id=38877
[6]: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1713490
P.S: As everybody else I don't mind so much on reverse migration to older
releases
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Fri, Jul 21, 2017 at 2:36 PM, Eric Blake wrote:
> On 07/21/2017 05:20 AM, Fam Zheng wrote:
> > It is reported that on Windows Subsystem for Linux, ofd operations fail
> > with -EINVAL. In other words, QEMU binary built with system headers that
> > exports F_OFD_SETLK doesn't necessarily run in
c=589631744})
[pid 13750] readv(0, [{iov_base="\r", iov_len=1}], 1) = 1
[pid 13750] writev(1, [{iov_base="\r\n", iov_len=2}], 1) = 2
[pid 13750] writev(1, [{iov_base="Block node is read-only\r\n",
iov_len=25}], 1) = 25
The last qemu I had around was a 2.8 where this works still fine.
If needed I might go bisecting but I have the feeling that I provided
enough data for the experts to easily "spot" it - so holding back the
bisect effort until needed.
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Fri, Aug 11, 2017 at 2:37 PM, Kevin Wolf wrote:
> Am 11.08.2017 um 14:04 hat Fam Zheng geschrieben:
> > On Fri, 08/11 13:07, Christian Ehrhardt wrote:
> > > Simplifying that to a smaller test:
> > >
>
[...]
> > > Block node is read-only
>
On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell wrote:
> On 18 January 2018 at 02:01, Eduardo Habkost wrote:
>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
>>
>> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into
>> staging (2018-01-16 17:36:
On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
wrote:
>
>
> On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:
>> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell
>> wrote:
>>> On 18 January 2018 at 02:01, Eduardo Habkost wrote:
>>&
On Tue, Jan 30, 2018 at 5:25 PM, Peter Maydell wrote:
> It seems like it's about time we settled on the dates for the
> 2.12 release. I've sketched in a suggestion at:
> https://wiki.qemu.org/Planning/2.12
>
> which puts softfreeze on the 13th March, hardfreeze a
> week later on the 20th, and fi
The hook already skips a set of rpm upgrade artifacts.
Do the same with such files that might be created by dpkg.
Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1484990
Signed-off-by: Christian Ehrhardt
---
scripts/qemu-guest-agent/fsfreeze-hook | 2 +-
1 file changed, 1 insertion
On Thu, Jan 18, 2018 at 2:15 PM, Cornelia Huck wrote:
> On Thu, 18 Jan 2018 13:47:54 +0100
> Christian Borntraeger wrote:
>
>> Have the x86 features been marked as stable? If the answer is yes,
>> shall we mark these patches for stable as well?
>
> Doesn't look like it.
>
> TBH, I'm not quite sur
Hi,
maybe I missed a formal thing on this submission, but I don't see it right away.
So for now just a ping on any updates in regard to accept this?
On Wed, Dec 13, 2017 at 11:17 AM, Christian Ehrhardt
wrote:
> The hook already skips a set of rpm upgrade artifacts.
> Do the same with
work for nested guests as well
which makes me able to drop that delta then.
> I'm concerned I will end up with a requirement for *all* guests to be
> restarted in order to migrate them to the new hosts, rather than just the
> ones that would have a problem.
>
> Thoughts?
>
> Thanks!
>
> --
> Mark Mielke
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Actually the qemu tasks are "invalid" not "incomplete" as they currently
are - after our discussions here it seems we agreed that qemu is doing
what is intended (and the reasons why larger bits are not the default).
Therefore set the status to that for the qemu tasks.
** Changed in: qemu (Ubuntu)
Crit prio on Qemu which was explained to work just fine is not correct IMHO.
After checking with David he meant to want to raise the prio on the suggested
libvirt extensions instead. I'm re-triaging this bug for that and will ping
David Berrange if work on this is already tracked on a libvirt-BZ
Reported to upstream libvirt's BZ with the suggestions of Daniel Berrage
and David Alan Glibert; now available at [1] I linked that up in the LP
bug status so that we auto-track this.
As eventually this has to go upstream using the bug tracker should
better ensure that there is no concurrent confl
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu
Status: New => Incomplete
** Changed in: qemu
Status: Incomplete => Opinion
** Changed in: qemu
Status: Opinion => Invalid
** Changed in: qemu (Ubuntu)
Status: New => Incom
And sorry for the status update noise, one can clearly see that I start
to fail once I have to use my mouse :-)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1722074
Title:
warning: host doesn't su
Hi,
this is not a show stopper at all.
It is just a warning and it is fine.
It is a trade-off between the "ease to use nested virt" vs "this warning".
For example on an intel chip you'd get:
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.8001H:ECX.svm
And that as
Note: The code change already passed the general regression checks on
the identical content against a PPA (Also on the weekend prior to the
full maturing period I'll have another automated run on proposed).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Running the Bionic ISO like:
$ qemu-system-x86_64 -cpu host -smp cores=4,threads=2 -boot d -m 2048
-enable-kvm -vga qxl -vnc :21 -cdrom ubuntu-18.04-desktop-amd64.iso
Attaching like:
$ vncviewer FullColor=1 AutoSelect=0 10.245.168.42:5921
(alternatives on tigervnc)
Well for me it had "-k de" as w
Thanks Leonardo for your check as well!
I agree that this particular issue here is fixed as we hoped.
The other one with the freeze did not occur for me, you might open another bug
if you have any pointers how we could go on on this.
--
You received this bug notification because you are a member
Arr reading is hard today, you had the other bug open already ... grml
:-)
Never the less - This bug here is fixed in the proposed version and for
now that is the important part.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:
Subscribed there as well now to stay on top of it if upstream gets to a
conclusion.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912
Title:
qemu-system-x86_64 crashed with SIGABRT when using o
Very interesting, Still not triggering for me :-/
Could you check if the PPA in [1] (with qemu 2.12 planned for Cosmic) already
fixes it for you?
[1]: https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3306/+packages
--
You received this bug notification because you are a member of qe
Link is better as https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3306
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912
Title:
qemu-system-x86_64 crashed with SIGABRT when using o
** Description changed:
[Impact]
- * An explanation of the effects of the bug on users and
-
- * justification for backporting the fix to the stable release.
-
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ * backport
Yeah we switched to gtk.
With OpenGL which do you mean - the virtgl based support or some other config
option?
Since it still fails to reproduce for me, but you already have a self build
qemu that is good.
Could you based on this build 2.12 from source as well and confirm that it
fails.
If it d
Nice, thanks Leonardo for the Bisect - lets call upstream Fixed
Committed then (as there is no 2.13 released yet).
For the separate gl discussion feel free to subscribe/chime in on bug
1657409
Currently 2.12 is on its way into Cosmic.
I'll add and test that patch afterwards, it looks small and sa
Tests are all ok, MP review was acked and case confirmed.
No Security Update since then in between, so sponsoring into SRU queue now ...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1587065
Title:
** Also affects: qemu (Ubuntu Bionic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912
Title:
qemu-system-x86_64 crashed with SIGABRT when using opt
Prior to the update:
$ virsh domfsfreeze x-freeze; virsh domfsthaw x-freeze
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command
'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy
Thawed 0 filesystem(s)
$ sudo apt install qemu-guest-
We have had a few more issues around armhf qemu-static that mostly resolved in
Artful (qemu 2.10) and finally one that was good in Bionic (qemu 2.11).
This also included some updates to other components but should be good now.
If the issue here really still applies to a newer version please reope
Fix is known and seems backportable, marking as server-next and subscribing for
somebody to take a look.
Also as mentioned it is in 2.9, so newer releases are already fixed.
** Also affects: qemu (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Stat
** Changed in: qemu (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1129571
Title:
libreoffice armhf FTBFS
Status in QEMU:
Won't Fix
Status in qemu
Clearing old bugs: No more occurring in any of my recent KVMs, setting
this old bug to incomplete.
** Changed in: qemu-kvm (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.l
Steps to reproduce
uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial label=daily
Add this to the guest definition and restart it
>From the hos
** Description changed:
+ [Impact]
+
+ * An explanation of the effects of the bug on users and
+
+ * justification for backporting the fix to the stable release.
+
+ * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+
+ [Test Ca
** Changed in: qemu (Ubuntu Xenial)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1587065
Title:
btrfs qemu-ga - multiple mounts block fsfreeze
Status in QE
** Changed in: qemu (Ubuntu Bionic)
Status: New => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912
Title:
qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl
St
On Thu, May 10, 2018 at 8:47 PM Philippe Mathieu-Daudé
wrote:
> Hi Paolo,
>
> On 04/24/2018 10:01 PM, Philippe Mathieu-Daudé wrote:
> > Hi Christian,
> >
> > On 04/09/2018 04:18 AM, Christian Ehrhardt wrote:
> >> Re-Ping for consideration?
> >>
&g
Yeah I even got help back then to make sure CCs are better but nothing happened.
Old thread:
http://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg02142.html
I re-pinged on the old thread to be reconsidered.
New Ping: http://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg03892.html
Tha
On Mon, Aug 20, 2018 at 4:32 PM Phillip Susi wrote:
> On 8/20/2018 4:43 AM, Gerd Hoffmann wrote:
> > There have been fixes for that one, specifically recent qemu will look
> > at modifier state in addition to the keysym when looking up the keycode,
> > because some keymaps can generate the same k
On Mon, Aug 20, 2018 at 9:51 PM Phillip Susi wrote:
> On 8/20/2018 11:07 AM, Christian Ehrhardt wrote:
> > What exactly would you need in Ubuntu Phillp?
>
> It *looks* like this is fixed in 2.12, but Ubuntu has 2.11.
>
> > Latest qemu would atm be on 2.12 with t
Working on Bionic SRu prep in https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/3367/+packages
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1755912
Title:
qemu-system-x86_64 crashed wit
** Description changed:
- When using qemu-system-x86_64 with the option -vga qxl, it crashes. The
- easiest way to crash it is by trying to change the guest's resolution.
- However, the system may randomly crash too, not happening only when
- changing resolution. Here is the terminal output of one
Since all but the libvirt task to expose these are set to invalid in
regard to the issue here I'm changing the title accordingly.
As a short term solution for Ubuntu users I forked bug 1776189 to
provide a machine type based solution until this here is implemented and
widely available and exploite
** Merge proposal unlinked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347796
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769053
Title:
Ability to control phys-
** Merge proposal unlinked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/347801
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769053
Title:
Ability to control phys-
1 - 100 of 271 matches
Mail list logo
