Dear Maintainer,

Using the Kernel in a Xen VM is not possible, booting with that image results in the error

Loading Linux 6.12.21-amd64 ...
error: not xen image.
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue...

Booting a self compiled Kernel is no issue though. VM type is "pv".

grub2 lacks any support to decompress zstd kernels.  This affects
booting xen pv via grub2, as there it needs to decompress the kernel
first.  grub2 itself contains support for zstd already, it just isn't
plumbed into the generic io filter via grub_file_filter_register

Relevant change to the Linux package:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1131

Bastian

grub2 lacks any support to decompress zstd kernels.  This affects
booting xen pv via grub2, as there it needs to decompress the kernel
first.  grub2 itself contains support for zstd already, it just isn't
plumbed into the generic io filter via grub_file_filter_register

Relevant change to the Linux package:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1131

Bastian

Dear All!

A previously mentioned workaround is to recompile the DomU kernel with
xz compression.

Another workaround is to not use pvgrub but make Xen boot the kernel
directly by changing the xl conf file to something like:
 kernel="/root/xen/images/debian13/devdev/incoming/latest_vmlinuz"
 ramdisk="/root/xen/images/debian13/devdev/incoming/latest_initrd"
 extra='root=UUID=b37347d8-3217-4a1b-81a7-5bc9f64ae059 ro
ipv6.disable=1 noacpi nolapic quiet'

For this, the kernel and the initrd file must be copied from DomU to
Dom0 (and after each kernel upgrade, it must be re-done), so it's less
convenient, but can be scripted and is working well. The package
needrestart is helpful to remind you about this additional step ;)

Another workaround is to use HVM mode, but that has severe performance
penalties.

I built a grub-x86_64-xen.bin with current grub (2.13) but even that
has the same problem as the version in trixie, so I will try to
contact the grub developers to move this issue forward.

Alternatively, is there a chance to have a linux-image-amd64-xz or
linux-image-cloud-amd64-xz or to switch linux-image-cloud-amd64 back
to xz?

Best wishes:
Elmar

I'm using Gandi.net as a VPS provider, and have upgraded my GandiCloud server
to Trixie.

Now, I run into this problem, and need a workaround that I can deploy without
access to the dom0.  So, changes to the xl conf file, or using HVM are, I
believe, impossible to implement.

Current workaround is to continue to use the "obsolete" linux-image from
bookworm that's still installed.