Arch Linux User Repository

@Refutationalist During package creation, Qemu configuration detects needed options, two additional files can be created: /usr/lib/xen/bin/qemu-keymap /usr/lib/xen/libexec/vhost-user-gpu

These two files should also be removed when assembling the xen package, but only if they are present.

@straybit & @FringeLunatic

I've been working on this on and off. Can either of you try building Xen in a clean chroot to see if you get the same conflict? My packages don't create a qemu-keymap at all, and I do not build my packages on my workstation.

Like ArthurBorsboom and FringeLunatic I also get a conflicting file error:

Packages (3) xen-4.16.1-1  xen-docs-4.16.1-1  xen-qemu-builtin-4.16.1-1
...
error: failed to commit transaction (conflicting files)
/usr/lib/xen/bin/qemu-keymap exists in both 'xen' and 'xen-qemu-builtin'
Errors occurred, no packages were upgraded.
==> WARNING: Failed to install built package(s).

Like ArthurBorsboom, I get a conflicting file error:

error: failed to commit transaction (conflicting files)
/usr/lib/xen/bin/qemu-keymap exists in both 'xen' and 'xen-qemu-builtin'
Errors occurred, no packages were upgraded.
==> WARNING: Failed to install built package(s).
==> Cleaning up...

Any way to fix this conflict without removing "qemu-keymap?" I believe this is a bug because both "xen" and "xen-qemu-builtin" own "qemu-keymap." I don't want to report it as such if there's something obvious I'm missing but I've found nothing about it until a user reported it here.

@Shapito You need to add the PGP key to your keyring to verify the signature, and patch is part of base-devel, which is always assumed.

I get two errors when try to install this package. ==> Verifying source file signatures with gpg... xen-4.16.1.tar.gz ... FAILED (unknown public key 83FE14C957E82BD9) ==> ERROR: One or more PGP signatures could not be verified!

And after adding --skippgpcheck makepkg flag usage. ==> Starting prepare()... ==> Applying GCC 12.1 fixes... /home/<user_name>/aur/xen/PKGBUILD: line 172: patch: command not found ==> ERROR: A failure occurred in prepare(). Maybe, you need to add patch dependency.

If I want to install the xen-qemu-builtin package, I have to manually delete two files, which conflict with the xen package; then it can be installed without a conflict. Is this caused by the xen package?

[arthur@xen1 xen]$ sudo pacman -U xen-qemu-builtin-4.16.1-1-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) xen-qemu-builtin-4.16.1-1

Total Installed Size:  244.04 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                                            [#########################################################################] 100%
(1/1) checking package integrity                                                                                          [#########################################################################] 100%
(1/1) loading package files                                                                                               [#########################################################################] 100%
(1/1) checking for file conflicts                                                                                         [#########################################################################] 100%
error: failed to commit transaction (conflicting files)
xen-qemu-builtin: /usr/lib/xen/bin/qemu-keymap exists in filesystem (owned by xen)
xen-qemu-builtin: /usr/lib/xen/libexec/vhost-user-gpu exists in filesystem (owned by xen)
[arthur@xen1 xen]$ sudo rm /usr/lib/xen/bin/qemu-keymap
[arthur@xen1 xen]$ sudo rm /usr/lib/xen/libexec/vhost-user-gpu
[arthur@xen1 xen]$ sudo pacman -U xen-qemu-builtin-4.16.1-1-x86_64.pkg.tar.xz

After last xen upgrade Im running into a strange error at bootup: none domain are up. Searching logs for a clue i found this:

May 31 11:08:16 bakaneko systemd[1]: Finished Xendomains - start and stop guests on boot and shutdown. May 31 11:08:16 bakaneko xendomains[369]: [done] May 31 11:08:16 bakaneko xendomains[369]: ! May 31 11:08:16 bakaneko xendomains[369]: An error occurred while creating domain new_moodle_eest1-vm.cfg: May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction of domain failed May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable to destroy guest May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-existant domain May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_create.c:1289:initiate_domain_create: Domain 4:Unable to set disk defaults for disk 0 May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_device.c:399:libxl__device_disk_set_backend: Disk vdev=xvda failed to stat: /dev/mapper/VM_bakaneko_vg-new> May 31 11:08:16 bakaneko xendomains[369]: new_moodle_eest1-vm.cfg

Despite this if xendomains is manually restarted everything boots up normally. Another error is related to qemu-dom0 backend:

May 31 11:36:42 bakaneko systemd[1]: Starting qemu for xen dom0 disk backend... May 31 11:36:42 bakaneko systemd[1]: Started qemu for xen dom0 disk backend. May 31 11:36:42 bakaneko qemu-system-i386[964]: qemu-system-i386: -xen-domid 0: Option not supported for this target.

Also at system upgrade a question arise for qemu-desktop replacement for qemu (dont know its related or not) Any suggestion? Thanks!!

Here is 4.16.1-1.

• Has patches to compile under GCC12, entirely by disabling some error checks.
• The hvmloader patch has been brought in, fixing that problem.
• I dropped working on the OVMF fixes, since that's a separate project from Xen.
• I have tested it on exactly two systems, both of which run AMD processors. Error reports and patches welcome.

UPDATE 2022-05-18: I have one machine running a Ryzen 7 5700G with an Intel 82576 that crashes on iommu. I'm attempting to get help with the problem, but if anyone else has a problem I'd like to hear about it.

@Sven I have a 4.16.1-0 in my repo that compiles cleanly except for stubdom, mostly thanks to an OpenSUSE patch that sets a bunch exceptions here and there. Still looking into the stubdom bit before I update AUR.