I'm on Arch, but that shouldn't matter. It's a clear bug in the
Makefile.
I note that Fedora doesn't ship these blobs as they're provide by
separate edk2 package.
Attached patch fixes it for me.
** Patch added: "edk2 Makefile fix"
Public bug reported:
DESTDIR installs end up with wrong paths in JSON files installed to
$prefix/share/qemu/firmware. For example, the file:
50-edk2-x86_64-secure.json
ends up incorrectly with:
"filename": "/build/qemu/pkg/qemu/usr/share/qemu/edk2-x86_64-secure-
code.fd",
instead of the
Thank you Max.
Can confirm your patch fixes my issue (qemu-img check ...)
Not sure about those other code paths. I don't use internal snapshots
and I'm not sure under which circumstances qcow2_free_any_clusters()
gets exercised.
Just for good measure, with patch applied I created another >4GB
Public bug reported:
Creating a compressed image then running `qemu-img check <..>.qcow2' on
said image seems to report bogus corruption in some (but not all) cases:
Step 1.
# qemu-img info win7-base.qcow2
image: win7-base.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk
Current trunk still displays the problem.
A git bisection between 4.0.0 and 4.1.0 revealed:
b6c246942b14d3e0dec46a6c5868ed84e7dbea19 is the first bad commit
commit b6c246942b14d3e0dec46a6c5868ed84e7dbea19
Author: Alberto Garcia
Date: Fri May 10 19:22:54 2019 +0300
qcow2: Define and use
This is due to the new way of configuring block devices in 4.2.
You'll need to create your snapshots correctly by using the '-F'
parameter of qemu-img create.
Full details here:
https://www.redhat.com/archives/libvirt-
users/2019-December/msg00016.html
--
You received this bug notification
Ping. Nobody else seeing this?
I can only assume you don't have keyutils-dev (or equivalent) installed
on your system.
This is a key difference (pardon the pun!) between Arch and the bigger
distros. Arch tends to avoid splitting development libs and headers into
separate packages, which might
Public bug reported:
When running qemu test suite I'm seeing a test failure:
ERROR:../qemu/tests/test-crypto-secret.c:144:test_secret_keyring_good:
assertion failed: (key >= 0)
Host is Arch Linux running in the standard Arch build environment
(essentially an nspawn container).
I first noticed
v2 patches appear to work fine in both test scenarios. Thanks again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1896096
Title:
Git version: Build process is broken in block_curl.c.o
Status in
** Attachment added: "meson-log.txt"
https://bugs.launchpad.net/qemu/+bug/1896096/+attachment/5413347/+files/meson-log.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1896096
Title:
Git
> Posted "[PATCH 0/4] configure: bugfixes and cleanups for CFLAGS".
(sorry for delay)
Thanks for the patches. They seem to fix the Arch case i.e. build
succeeds without hacks and FLAGS in the build env are being respected.
However, I tested the "unset FLAGS" case and patch 4/4 seems to cause a
Chiming in here as the user who initially suggested Arch use this:
--extra-ldflags="$LDFLAGS"
qemu-5.0.0 introduced a breaking change whereby LDFLAGS from the
environment were ignored. For Arch, this resulted in exclusion of `--as-
needed' from the link, which naturally caused dependency chaos.
Already reported to Arch:
https://bugs.archlinux.org/task/68061
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1898215
Title:
[git][archlinux]Build process is busted in spice-display.c
Status in
Hi Paolo,
The CFLAGS patches seem to have missed your last big pull req:
[PULL v8 00/86] Misc QEMU patches for 2020-09-24
Apparently disappeared between v3 and v4. Oversight or intentional?
Thanks.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Looking deeper into this... I believe there are indeed qemu bugs here.
It's actually the qemu configure script which is adding `-pie'
$ echo $LDFLAGS
-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
Yet meson-logs/meson-log.txt tells me that:
Using 'LDFLAGS' from environment with value: '-g
> So we need to unset CFLAGS and LDFLAGS in the configure script.
Yes, but is this what you really want? It seems to go against standard
practice. The usual expectation is even documented in Meson docs:
https://mesonbuild.com/howtox.html#set-extra-compiler-and-linker-flags-
strace shows the problem:
add_key("user", "qemu_test_secret", "Test Payload", 12,
KEY_SPEC_PROCESS_KEYRING) = -1 EPERM (Operation not permitted)
It appears systemd-nspawn containers don't have CAP_SYS_ADMIN which is
apparently needed for the keyring stuff to work. Fair enough.
But the
> systemd-nspawn containers don't have CAP_SYS_ADMIN
Above statement is utter bollocks. Please ignore..
I finally got to the bottom of all this and now have the test suite passing.
- don't use `--disable-keyring', it's busted
- systemd-nspawn containers need to be configured with additional
I only enable a few emulators and qemu-system-s390x isn't one of them.
I was thinking it couldn't be useful on an x86_64 host, even if using
the qemu-system-s390x emulator! I guess my understanding was wrong. Will
close as invalid.
** Changed in: qemu
Status: Incomplete => Invalid
--
Public bug reported:
This is latest release QEMU-5.2.0 on Arch Linux running kernel 5.10.13,
latest OVMF etc.
I'm seeing the following crash when loading an audio driver from the
OpenCore[1] project in the UEFI shell:
KVM internal error. Suberror: 1
emulation failure
RAX=
Public bug reported:
Hi
Test building latest 6.0.0 release candidate on x86_64 host. A new
module has appeared:
/usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so
Unless I'm missing something obvious, it would appear to be only useful
on s390x platform.
Why would I need this? For me it doesn't seem to
21 matches
Mail list logo
