Arch Linux User Repository

We've moved to the newly-stable 4.20.0 branch. There are also other changes:

• stubdom is fixed by disabling the vtmp and vtpmmgr components. This gets rid of a few source files and our remaining patches.
• Debug files are only removed if the debug option is not set in makepkg.cfg (or the PKGBUILD itself)
• pygrub has been removed
• optdepends are adjusted for the upcoming xen-grub split package for the various Xen flavored builds.

If you're still using pygrub note that it is deprecated. The solution is to build PV grub instead, which used to be in AUR but is now missing. I am asking a couple questions on the mailing list, and I intend to put my current build of xen-grub (which supersedes xen-pvhgrub) on AUR as soon as possible. If you need to build it before that occurs, you can find it in my PKGBUILD repo.

EDIT: 4.20.0-2 adds support for the xen-edk2 package, which has a fixed UEFI for xen

Xen installs the /usr/lib/modules-load.d/xen.conf file. It also contains (historic) module names that do not exist in our distribution. systemd-modules-load.service will exit with failure for these nonexistant modules, but boot does continue. see:pacman -Ql linux | grep -E 'xen-' https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100#comment-622244

Ah, thanks.

My second GRUB patch null config filename we could workaround by installing: /boot/config-${linux pkgbase} with CONFIG_XEN_DOM0=y in a pacman hook? But this is only appropriate to booting Xen with GRUB on Arch. I will open bug upstream and pursue it there as well.

Thanks! Please post a link when you do :)

Hey FF,

Great to see progress.

modules-load.d/xen.conf

Xen installs the /usr/lib/modules-load.d/xen.conf file. It also contains (historic) module names that do not exist in our distribution. systemd-modules-load.service will exit with failure for these nonexistant modules, but boot does continue. see:pacman -Ql linux | grep -E 'xen-' https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100#comment-622244

GRUB helper fixes upstream

Yes, will try for GRUB helper upstream changes.

Should not need my first GRUB patch -vmlinuz-*, +vmlinuz anymore, as it looks like mkinitcpio installs kernel as vmlinuz-${pkgbase} now I use dracut, so I cannot check this on system. https://git.archlinux.org/mkinitcpio.git/tree/libalpm/scripts/mkinitcpio-install

My second GRUB patch null config filename we could workaround by installing: /boot/config-${linux pkgbase} with CONFIG_XEN_DOM0=y in a pacman hook? But this is only appropriate to booting Xen with GRUB on Arch I will open bug upstream and pursue it there as well.

Cheers

I think we should work on fixing the issue in the upstream (so, grub) and backport the patch to the grub package. Do you want to do it? Since you wrote the patches.

The two last patches that is. For the first we should open a bug report for grub package.

Hey, sorry for the delay catching up.

ovmf typo in your PKGBUILD optdepends and Xen configure option Package has /etc/init.d/ files

Fixed (locally).

Maybe some sort of install message about: - booting Xen & enabling services? (Xen gets booted before linux dom0) - fixing dom0 memory in the bootloader Xen hypervisor config

Will add before moving to the repos.

Worth cleanup of usr/lib/modules-load.d/xen.conf to avoid modules load errors: I used this in prepare(). find tools -iname 'configure*' -exec sed -i -E -e '/^LINUX_BACKEND_MODULES="$/,/^"$/{/"/b;/^xen-/!d;s/scsibk/scsiback/;};' {} \;

Can you explain exactly what is the issue here?

GRUB helper for loading the Xen dom0: It might be better to fix the Arch grub package with a patch so that 20_linux_xen works for arch kernel? My old changes linked. Need retesting. - vmlinuz- - don't fail on no /boot/config file - ignore xen files grub cannot boot

I think we should work on fixing the issue in the upstream (so, grub) and backport the patch to the grub package.

Do you want to do it? Since you wrote the patches.

Hey FF,

Have not yet had a chance to install and test, but looking over it again:

• ovmf typo in your PKGBUILD optdepends and Xen configure option
• Package has /etc/init.d/ files
• Maybe some sort of install message about:
• booting Xen & enabling services? (Xen gets booted before linux dom0)
• fixing dom0 memory in the bootloader Xen hypervisor config

• Worth cleanup of usr/lib/modules-load.d/xen.conf to avoid modules load errors: I used this in prepare(). find tools -iname 'configure*' -exec sed -i -E -e '/^LINUX_BACKEND_MODULES="$/,/^"$/{/"/b;/^xen-/!d;s/scsibk/scsiback/;};' {} \;

• GRUB helper for loading the Xen dom0: It might be better to fix the Arch grub package with a patch so that 20_linux_xen works for arch kernel? My old changes linked. Need retesting.

• vmlinuz-
• don't fail on no /boot/config file
• ignore xen files grub cannot boot

Cheers

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?).