[Pkg-xen-devel] Bug#975062: Python 3 (pygrub) in 4.14 packages

[Ian Jackson]

Hans van Kranenburg writes ("Bug#975062: Python 3 (pygrub) in 4.14 packages"):
> So, apparently there are cases in which pygrub 'works' and in which it
> does not, and apparently using pygrub with "amd64 kernel and Xen tools
> but i386 userland" is problematic, and I remember some remarks which I
> can't find back about that that use case was probably already broken
> always, in the past.

The problem with pygrub with 32-bit userland is as follows:

 * Xen has to be 64-bit since there is no 64-bit Xen.

 * dom0 kernel bitness and Xen tools bitness must match because
   Xen 32/64 compat ABI understands only one bitness for dom0
   and Xen dom0 tools make hypercalls directly so must match
   the kernel.

 * 32-bit kernels are starting not to be able to drive hardware
   (big PCI bars, bugs, etc.) so you want a 32-bit kernel.

 * So you must have libxen*:amd64.

 * pygrub uses python, obviously.  It needs to load the xenfsimage
   library, which is part of xen tools, since that is the userland
   library tht understands the guest filesystem to fish out the guest
   kernel.

 * The xenfsimage library is not in its own package [1] - it's in with
   some other Xen libraries.  But it is going to be loaded into a
   python interpreter, so it needs to match the bitness of the python
   interpreter.

 * You can't install a 64-bit python interpreter without basically
   doing the whole 32-to-64 crossgrade.  (That crossgrade is what I
   ended up doing on my home machine.)

 * You can't co-install libxen*:i386 because the Xen libraries aren't
   properly multiarched. [2]

 * This gets worse now that the Xen packages use python3.  Previously
   with a minimal but modern system you might be able to get away with
   having a 64-bit python2 and a 32-bit python3.

Both [1] and [2] are in principle bugs in the Xen packages.  Upstream
sentiment seems to be that 32-bit userland is not really a very good
idea any more anyway.  So we could solve this by fixing [1] or [2] or
we could expect people to use 64-bit dom0 userland (and crossgrade if
need be).

> I wanted to find out about this and set up some test cases to reproduce
> things (I've never used pygrub yet), but that obviously did not happen
> yet. I have some stuff going on in my personal life that is taking up a
> lot of time currently. What is rather easy for *me* is to help
> organizing the work and managing todo lists etc, but not learning new
> stuff ATM.
> 
> So, my current questions are:
> 
> 1. Is pygrub a blocker for having Xen 4.14 in unstable? Because that
> should be our first team-goal now.

I think yes, a working pygrub ought to be a blocker for 4.14 in
unstable.

But I think we have that - I rebuilt the existing packages for buster
and it WFM.

> 2. What exactly is going on, can we make a list/table/whatever about in
> which cases pygrub 'does not work' (in more detail, how does it fail).
> 3. pygrub keeps being the thing that always causes problems. What would
> be your (asking anyone who wants to think along) ideas about which
> well-defined situations/test-cases we should have to execute instead of
> having the users report problems after big package changes?

IDK about any other problems than the bitness one above.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.