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

[Hans van Kranenburg]

Hi!

On 11/18/20 6:45 PM, Ian Jackson wrote:
> 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.
                                            ^^ 32?

>  * 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.
                                              ^^ 64?

>  * 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]

My personal opinion is that there are more interesting horses to fry (or
what was the saying) for our very bandwidth limited team. So yes, let's
move this from the perfection into the known issues department for now
(bullseye).

> or
> we could expect people to use 64-bit dom0 userland (and crossgrade if
> need be).

When someone shows up with a real world issue who's really panicing
after recklessly upgrading (after the bullseye release halfway 2021) we
probably might help by giving pointers and instructions. Until that
actually happens, we should not spend time writing documentation about
how to do that etc.

>> 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.

OK.

>> 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.

Ok, thanks a lot for the write up, both, and now we have a debian bug to
look back to which is a bit easier to track than mailing list messages.

So, I'm crossing out this issue now as blocker.

Hans