[PATCH v6 00/17] efi_loader: add capsule update support

Tom Rini trini at konsulko.com
Fri Sep 11 04:44:54 CEST 2020


On Fri, Sep 11, 2020 at 11:31:11AM +0900, AKASHI Takahiro wrote:
> Tom,
> 
> On Thu, Sep 10, 2020 at 09:02:59PM -0400, Tom Rini wrote:
> > On Fri, Sep 11, 2020 at 09:52:10AM +0900, AKASHI Takahiro wrote:
> > > On Wed, Sep 09, 2020 at 10:58:53PM -0400, Tom Rini wrote:
> > > > On Thu, Sep 10, 2020 at 11:52:37AM +0900, AKASHI Takahiro wrote:
> > > > > On Wed, Sep 09, 2020 at 12:56:28PM -0400, Tom Rini wrote:
> > > > > > On Wed, Sep 09, 2020 at 04:48:30PM +0200, Heinrich Schuchardt wrote:
> > > > > > > On 07.09.20 07:34, AKASHI Takahiro wrote:
> > > > > > [snip]
> > > > > > > > required and partly because there is a problem with virt-make-fs.
> > > > > > > 
> > > > > > > What problem with virt-make-fs exists? How will this be solved?
> > > > > > 
> > > > > > This I suspect is related to the difficulty of getting tests to run in
> > > > > > all of our CI environments, where at least in one case they run and
> > > > > > pass, rather than skip.  This will require that the series get run
> > > > > > through at least Travis and Azure before re-posting, at this point.
> > > > > > Thanks.
> > > > > 
> > > > > I think that we discussed this issue several times before.
> > > > > 
> > > > > https://lists.denx.de/pipermail/u-boot/2020-July/419430.html
> > > > > https://lists.denx.de/pipermail/u-boot/2020-July/420712.html
> > > > > 
> > > > > I have not implemented a fallback handling in case of virt-make-fs failure
> > > > > as Heinrich doesn't like it (even dropped the code from my patches.)
> > > > > 
> > > > > The only solution is Heinrich's patch:
> > > > > https://lists.denx.de/pipermail/u-boot/2020-July/419976.html
> > > > 
> > > > The problem is that Heinrich's patch breaks things.  A complete solution
> > > > is required.
> > > 
> > > What kind of issue did you see?
> > 
> > I believe it's in the thread.  But in short, we then stop running the
> > other filesystem tests as they get skipped.
> 
> I believe that the reason of failures in filesystem tests is the same;
> /boot/vmlinuz* have not 'read' permission to users and any commands
> in libguestfs-tools, including guestmount and virt-make-fs, cannot
> set up a virtual machine internally used in those commands.
> 
> So again, the only solution is to apply Heinrich's patch.

No, I believe I fixed that as part of digging in to this at the time.

> > > > That patch might be part of the solution, along with
> > > > perhaps a rework of the logic to try and gracefully catch and re-try
> > > > when we have a problem with one of the possible tools.
> > > 
> > > Anyway, I can't do anything here as Heinrich rejects any sudo-based
> > > solution. See:
> > > 
> > > https://lists.denx.de/pipermail/u-boot/2020-July/419951.html
> > > 
> > > So he is responsible for fixing it.
> > 
> > No, it's on you to provide a solution that runs in both CI and developer
> > machines.  It's not sudo or make-virt-fs, it's get the try/catch logic
> > correct in the test framework such that if we can't run sudo
> 
> The point is that Heinrich doesn't accept any sudo solution and that
> he modified my tests to solely use virt-make-fs by the patch above.
> So what can I do here?
> 
> > we do run
> > make-virt-fs, and if we're able to run the tests somehow, we run the
> > tests somehow.
> 
> Again, Heinrich's patch will fix it.

Please put together a series that passes and runs on CI and doesn't make
other tests stop running.  That's the requirement.  If it doesn't run in
CI, it doesn't get run frequently enough.  If it makes some CI tests
stop running, that's a problem too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200910/3142d24f/attachment.sig>


More information about the U-Boot mailing list