[Pkg-xen-devel] Bug#1028251: New Patch (Was: Re: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64)

[Chuck Zmudzinski]

On 1/13/2023 9:08 PM, Chuck Zmudzinski wrote:
> On 1/13/23 6:59 PM, Hans van Kranenburg wrote:
> > Hi,
> > 
> > On 1/13/23 22:45, Chuck Zmudzinski wrote:
> >> On 1/13/23 7:39 AM, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2023 at 12:58:29AM -0500, Chuck Zmudzinski wrote:
> >>>> On 1/11/2023 10:58 PM, Chuck Zmudzinski wrote:
> >>>>> On 1/9/23 12:55 PM, Hans van Kranenburg wrote:
> >>>>>> Hi!
> > [...]
> > Yolo style cutting out lines here...
> > [...]
> >>>>
>
> >> 
> >> Perhaps this is an opportunity for you to try to fix 922033 again.
> >> I see it has been sitting there for a few years now. Let's see
> >> what Hans thinks.
> > 
> > Yeah, well, so, the thing here is...
> > 
> > When Debian started to package Xen (thanks! Bastian, in 200X), the
> > upstream init scripts were copy pasted, and adjusted to have the ability
> > to have different Hypervisor-ABI-incompatible versions installed at the
> > same time. Also, this is related to the collection of Makefile patches
> > we carry around to have ABI-incompatible stuff end up in a directory
> > like /usr/lib/xen-4.14/ and /usr/lib/xen-4.17/ !
>
> That is a nice feature of the Xen Debian packages, to have the ability
> to manage guests on different versions of the hypervisor.
>
> > 
> > What does this mean? Well, in the most basic sense it means that you
> > could apt-get (dist-)upgrade and then still be able to xl shutdown a
> > domU afterwards before doing reboot, because it will choose the right
> > tools which match with the ABI of the *now* running hypervisor instead
> > of being left with a dumpster fire, which in the end causes you to shout
> > curse words and cause you to have to go to the machine and hold the
> > power button for 5 seconds to force power it off.
> > 
> > This is the thing about where you upgrade from Xen 4.14 to Xen 4.17
> > during the upgrade from Debian 11/Bullseye to Debian 12/Bookworm, it
> > will allow you, if booting the whole new thing is a huge failure, to
> > reset the computer, and in grub, choose to use the previous Xen (and
> > possibly do that in combination with previous Debian linux kernel) and
> > then have a system where you again at least can start your domUs again
> > *) and first have a good rest, night of sleep before starting to dig
> > into what's going wrong.
> > 
> > So, this is exactly the same way of doing stuff like how you can also
> > reboot back into the previous Linux kernel (ABI-compatible) one during a
> > system upgrade, even if you're not using Xen at all!
> > 
> > I like this very much. This is the kind of thing that helps admins of
> > systems that have just local disks and a few domUs. Like, the case where
> > you support some non-profit organization with their server stuff running
> > on donated hardware. (Yes, I also do some of those, I do!) And, in case
> > something does fail (there could always be something like a misbehaving
> > mpt3sas card in the hardware or anything that no one else spotted yet),
> > the admin does not have to end up in total panic mode after doing the
> > upgrade on a Friday afternoon lying upside down inside a broom closet,
> > but they can just at least recover from the situation and have something
> > that's running again, and then a day later, or 2 or 3 days or a week
> > later return on another planned moment to fix it, after asking around.
> > 
> > Upstream Xen stuff doesn't have anything like that.
> > 
> > But, they actually look at us, and they think, ooh, this is actually
> > nice, we should have that also by default.
> > 
> > The fact that we have this changed/altered/divergent init scripts in
> > Debian is the main reason that we cannot just enable systemd things
> > which will put upstream whatever on the system.
>
> I understand the problem here.
>
> > 
> > So, what could we do about this?
> > 
> > The project plan (that could be drafted on an A4 paper) could look like,
> > gather around all distro maintainers of Linux distro's that are shipping
> > Xen, and then search for a 'Project owner', which we totally need to be
> > someone that is actually employed at a company that actually cares about
> > getting the results of this.

"Totally need to be someone that is actually employed at a company." I am curious
about that statement. Has Debian given up on the idea that members of the FLOSS
community can band together and solve a problem like this without corporate
backing? I don't think other distros have given up on that idea: For example, Fedora has
its community spins, a KDE spin, for example. Perhaps a Xen spin at Fedora could lead
this project. But why not Debian, with all it's derivative distros pitching in to help? I think
maybe the conclusion to draw from the statement that it has to be someone actually
employed at a company really means there is not enough community for support for
Xen to do this, Xen just is not a very big priority for the larger FLOSS community any
more. AFAIK, Qubes is the only project downstream of Xen that is serious about making
Xen work for desktop virtualization. Thanks, Marek, for the great work you have been
doing!

Kind regards,

Chuck