[Pkg-xen-devel] [PATCH 01/19] debian/rules: Correct shim install step for current Xen

Elliott Mitchell ehem+debian at m5p.com
Fri Dec 4 20:53:26 GMT 2020


On Fri, Dec 04, 2020 at 09:07:22PM +0100, Hans van Kranenburg wrote:
> On 7/17/20 7:16 AM, Elliott Mitchell wrote:
> > When originally implemented, the separated shim install step relied on
> > the shim install being a NOP on shimless architectures.  Either this is
> > no longer the case, or else cross-building confuses the architecture
> > detection.
> 
> Ian, this one is for you. I really do not have the capacity to figure
> out all of this shim stuff intricacies. :|
> 
> Elliot, You're telling you're fixing a problem, but not what the problem
> was that you have been seeing. Was there a build failure? What did it
> look like? Do you still have the full build log up until it failed?

I don't know everything about everything Xen either.  I can point to
038714d4ee4 and the comment as a likely source of information.  Yes,
there was a failure during the packaging steps (install failing for
arm64).  I was guessing the "install-shim" step shouldn't be run on
arm64.

Looking at the rest of the comment though, I'm now wondering if the
situation is rather worse.  Also looks like more commentary adjustment
is needed.  :-(


> We ran into a build failure for i386 during trying to get 4.14 in
> Debian, which was the shim not being built for the i386 package while it
> was expected to be there as result.

Very possibly you were running into the exact same thing I was:  The
"install-shim" target is no longer a NOP on shimless targets.  As such
perhaps the install-shim step needs to be amd64-only?  This might
actually be a Xen bug.


> What I finally did was taking a bigger hammer and invent a workaround by
> reverting some upstream commit from 4.12 that changed the way of
> determining to build shim or not, because I had no idea about how this
> change did break our things. What I did is not optimal and/or
> future-proof, but it got the thing in unstable.
> 
> So that's the following part of debian/changelog:
> 
> * Revert upstream commit a516bddbd3 ("tools/firmware/Makefile:
> CONFIG_PV_SHIM: enable only on x86_64") and cherry-pick our previous
> commits 0b898ccc2 ("tools/firmware/Makfile: Respect caller's
> CONFIG_PV_SHIM") and a516bddbd3 ("tools/firmware/Makefile:
> CONFIG_PV_SHIM: enable only on x86_64") again to work around a FTBFS
> where the shim would not be built during the i386 package build.
> 
> That's what's in Debian unstable/testing now. Is your
> development/testing based on that, or something else?

Yes.  Some portion of my running system broke though and now I'm hunting
for another major problem.   :-(


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445





More information about the Pkg-xen-devel mailing list