[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

surprises when using latest Xen in Jammy



Hi xen-users,

https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1956166

Noticed above BR and see that they don't want to move Xen in 22.04
past xen-4.14.3, which is for Debian stable, called Bullseye.

This means that the new zst kernel compression and dpkg internal zst
archives will doom them from packaging Xen for Jammy.

// demo the zst internals
$ ar -tv xen-hypervisor-4.15-amd64_4.15.1-1+ub22u04.1_amd64.deb
rw-r--r-- 0/0      4 Dec 29 18:01 2021 debian-binary
rw-r--r-- 0/0   1234 Dec 29 18:01 2021 control.tar.zst
rw-r--r-- 0/0 3991132 Dec 29 18:01 2021 data.tar.zst

 /usr/bin/ar is provided by binutils

// can't debootstrap Jammy in Bullseye
My Ubuntu buildroot for Xen was hosted by Bullseye until I tried to
create a Jammy chroot.
It fails due to the zst compressed dpkg internals.
This caused me to move my Ubuntu buildroot to Focal.

Since Dec 2 I have a Jammy domU running pv in a xen-4.15.1 dom0
(AlmalLinux 8. To set that up I used a debootstrap image, as made in
Focal.

We have source builds of xen-4.15.1 and xen-4.16.0 for Jammy too. The
dom0 works great even on older HW, Ubuntu has no poison pill in glibc
as does RH9/el9, which won't run right on older HW.

Nobody I talked to has any info as to why Debian won't move to zst
support in dpkg and kernel, which started 3 years ago in Ubuntu. Even
Bionic has this support backported into dpkg.

cheers,
Happy New Year,
PryMar56

Attachment: ub2204-xen-415.png
Description: PNG image


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.