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.

Dear All!

Grub developers are working on this, I saw a patch on the grub-devel
mailing list, there is a good chance that this will soon work (maybe
in the next grub release?) and then can be properly backported or QaD
binary dropped into older systems (like stable and oldstable) to boot
Trixie with PvGrub2.

Cheers,
Elmar

Hello,

I've created some patches for grub that adds zstdio support to boot
kernels compressed with zstd. I just sent them upstream a few minutes
ago[1].

I've attached a patch which I've used to successfully build Debian
packages that, when installed on the Xen guest, will boot standard
Trixie kernels.

I've also placed some very unofficial pre-built packages to tide other
people in the same boat over while this gets sorted out:

https://staff.deltatee.com/~logang/grub/

Thanks,

Logan

[1] https://lists.gnu.org/archive/html/grub-devel/2025-09/msg00227.html

Hello,

I've created some patches for grub that adds zstdio support to boot
kernels compressed with zstd. I just sent them upstream a few minutes
ago[1].

I've attached a patch which I've used to successfully build Debian
packages that, when installed on the Xen guest, will boot standard
Trixie kernels. I've also attached entirely unofficial pre-built
packages to tide other people in the same boat over while this all
filters through.

Thanks,

Logan

[1] https://lists.gnu.org/archive/html/grub-devel/2025-09/msg00227.html

Dear All!

I built a PvGrub2 binary (from v. 2.13 commit
ee789e1a625a43b31e17f91a11d4cfb609bc4c52) with Logan Gunthorpe's patch
that can be binary dropped to a Xen Dom0/host to boot a
zstd-compressed Trixie kernel in a DomU/guest.

The file is attached - booting it with
 kernel = "grub-x86_64-xen.2.13_with_zstd_dom0.bin"
from a xl.cfg file boots my test subject.

Build instructions for in-house binaries (preferably in a VM, don't
break your boot loader):
git clone git://git.savannah.gnu.org/grub.git ; cd grub
# Install tools and dependencies - see ./INSTALL
# Apply Logan Gunthorpe's patch (patch --verbose -p1 -i zstdio.patch)
./bootstrap
./autogen.sh
./configure --target=amd64 --with-platform=xen
make
make install
grub-mkimage -O x86_64-xen -c xen.grub.cfg -o
grub-x86_64-xen.2.13_with_zstd_dom0.test.bin -p
/usr/local/lib/grub/x86_64-xen/*.mod

Best wishes:
Elmar

Hi,

I found an issue with my above patch. A change needs to be made to
10_linux configuration to ensure the zstdio io module is installed.

I've attached an updated patch and updated the packages I provided here:

https://staff.deltatee.com/~logang/grub/

Thanks,

Logan

The patches have been accepted by the upstream project for 2.14-rc1.

Can anything be done to include the patch in an official Debian package
for Trixie? Or are we stuck with the issue until Forky?

Thanks,

Logan

Dear maintainers,
Is there any way to get that patch to Trixie? If updating via point
releases and s-p-u isn't possible, would doing a backport be an option?

The current situation forces one to either stick with Bookworm kernels or
to roll self-made grub packages -- both is far from being perfect.

I rely on working PV grub as I do make use of PCI pass-through on several
host systems which require PV instead of PVH (which works just fine).

Thank you for considering this and all the best,
    Adi