Arch Linux User Repository

As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?

Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur

I think I fixed everything in the PKGBUILD[1]. Both the updated xen package and a qemu package built with --enable-xen are available in my repo[2]. Could you guys please try it and let me know if there are still are any issues?

Regarding the bootloader, the pvgrub helper is packaged but it is broken. This is an upstream issue, I am going to contact them. Basically, in Python 3.8 the descriptor flags for native modules are checked when the module is imported, as opposed to when a certain method is called. This causes the xen.lowlevel.xc to fail to import. This should be a quick fix from the upstream, I had a look but couldn't find the culprit (the python error message could be a little more verbose :P).

Also, if you want UEFI support you will need the ovfm package from [testing].

[1] https://paste.xinu.at/mbZ/ [2] https://pkgbuild.com/~ffy00/repo/

Hi FF, With my own built and installed Xen git master:

The OVMF package in Arch [testing] now includes OVMF.fd, and that boots for me. I tested a boot to EFI BIOS & linux had populated /sys/firmware/efi/efivars/

Tested with: domU.cfg options

bios = "ovmf"
bios_path_override = "/usr/share/ovmf/x64/OVMF.fd"

I cannot use the current Arch system QEMU:

tail /var/log/xen/qemu-dm-*.log
qemu-system-x86_64: -xen-domid 11: Option not supported for this target

Tested with: domU.cfg options

device_model_version = "qemu-xen"
device_model_override = "/usr/bin/qemu-system-x86_64"

To use Arch system QEMU would require some changes in the Arch qemu package. At least makedep xen for the header files, and compiled with --enable-xen, and possibly --enable-xen-pci-passthrough Then check qemu still functions without the xen headers, or split these headers from the xen package and depend on them in qemu? https://packages.debian.org/sid/amd64/libxen-dev/filelist

If you want to move this packaging planning somewhere else, let us know.

Cheers

Hi FFY00,

Other things that could be improved in your PKGBUILD, you can use Arch Linux's SeaBIOS, with:

./configure --with-system-seabios=/usr/share/qemu/bios-256k.bin

For backup=(), this is probably the list of configuration file:

etc/default/xencommons
etc/default/xendomains
etc/xen/cpupool
etc/xen/xl.conf
etc/xen/scripts/*

Cheers.

It almost builds. It builds, but then fails when packaging here: mv "${pkgdir}/usr/lib64/efi/xen".efi "${pkgdir}/boot". The folder .../lib64 doesn't exist, and xen.efi isn't built. I don't have any idea why. After all the build works (after using the patched PKGBUILD). Can somebody explain why the xen.efi binaries aren't built? Tried to understand the makefiles, ..I guess some precondition isn't met but I have no fing idea.

It builds fine (is valgrind necessary? quite a large dependency).

Got this when trying to install: https://gist.github.com/invisiblek/01920f2b63f37e7d0d317ae549c9de00 It's due to an empty /usr/lib64 dir in the package which is residual from the mv of efi in package() function. Add an rmdir "$pkgdir"/usr/lib64/ after the mv on line 97 and it installs fine.

Your PKGBUILD does not include a grub helper like this one does, so creating a grub config would have to be done manually or something after installation. I'm not sure the best way to handle that situation (for an official build you probably need to handle more than just grub as the user's bootloader?).

FF,

I have not yet tried your package, just had a quick look over it.

It has been years since I tried to use Arch system qemu and ovmf (typo in your optdepends), and it would be delightful to find these just worked now...

When I did:

• Xen could not use OVMF's code.fd and vars.fd separately. It would be very simple to split Arch's OVMF package to ship the unified file in another package. The Arch bug has been ignored for years https://bugs.archlinux.org/task/58635

• QEMU seems to need to be built with Xen headers in place for Xen backend support Debian installs libxen-dev before building QEMU https://salsa.debian.org/qemu-team/qemu/-/blob/debian-unstable/debian/control-in https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/control Xen uses --enable-xen for the in-tree copy https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/Makefile;h=c10946e3b15a5a14aa83e4bbfda759b3681692de;hb=HEAD#l241

It would be great to see this tested and packaged. Cheers

Hey guys. I have been working on a PKGBUILD but haven't been able to test it.

https://paste.xinu.at/6PR/

Can anyone see if there are any issues? If everything is fine we can go ahead and move it to the official repos.

This commit fixes the current build issue: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=368375d7360a38c27de8e0276498bdd29e9e8a03

Sadly that commit hasn't been backported to the 4.12 branch, so it has to be patched during makepkg. I suppose you could also downgrade your ocaml to something before 4.09 and things would work again too...but that seems foolish.

Possible solutions here:

1. Fix up the current 4.12.1 build like so: https://github.com/invisiblek/xen-aur/commits/4.12.1-2

2. Step one plus update to 4.12.2 while we're at it: https://github.com/invisiblek/xen-aur/commits/4.12.2-1

3. Move to 4.13.0: https://github.com/invisiblek/xen-aur/commits/4.13.0-1

All three do require this minor patch to remove a now deprecated flag in qemu: https://github.com/invisiblek/xen-aur/commit/168fbdaa33265c4902ebfd5e8def892b0c2c14ca

I'll be testing with my 4.13.0-1 branch for now.

I see FFY00 mentioned official repos a couple months ago, unsure the status on that as of yet. Maybe I'll ping them on irc one of these days and see where that whole thing is at.

For now at least we can have working builds again :)

Getting the same error as @schweratlet, installing with pikaur.

@mbroemme I'm getting the same error when trying to install (installing with yay -S xen. though I hope it doesn't make a difference.

make -C xentoollog install make[8]: Entering directory '/home/shogoro/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog' python2 genlevels.py _xtl_levels.mli.in _xtl_levels.ml.in _xtl_levels.inc MLDEP MLC xentoollog.cmo MLA xentoollog.cma CC xentoollog_stubs.o xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage': xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 93 | value func = caml_named_value(xtl->vmessage_cb) ; | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress': xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 123 | value func = caml_named_value(xtl->progress_cb) ; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors )

It leaves a whole bunch of directories and then.

make[1]: [Makefile:74: install] Error 2 make[1]: Leaving directory '/home/shogoro/.cache/yay/xen/src/xen-4.12.1/tools' make: [Makefile:127: install-tools] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Error making: xen

Is this in any way my fault? Any advice? I have installed Xen successfully before, more specifically twice 4-5 months ago both on a fresh install. This is the first time I'm encountering such an error. I've tried it several times.