Re: [PATCH 0/9] first wic integration

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 31 Jan 2018 13:15:28 +0100
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

> On 2018-01-31 13:02, Baurzhan Ismagulov wrote:
> > On Wed, Jan 31, 2018 at 12:47:08PM +0100, Jan Kiszka wrote:  
> >>>> If the manual non-root call did work before, i will look into
> >>>> that.  
> >>>
> >>> Yes. Yes, please do.
> >>>
> >>> In Yocto, manual non-root call works. The same is our vision for
> >>> Isar. For now, it has been workarounded with sudo. We have a
> >>> working PoC based on PRoot in the pipeline. So I don't support
> >>> the idea of changing the user experience because of this issue.  
> >>
> >> While I agree we should try to get whole Isar unprivileged, let's
> >> not invest too much into this when it's complex. We are currently
> >> far away from that goal (as you know, proot has several open
> >> issues as well), and this here solves the problem of having to run
> >> wic manually at all.  
> > 
> > No effort whatsoever. This is already workarounded in master in the
> > following commit:
> > 
> > bf873d3 wic: Use sudo instead of pseudo
> >   
> 
> This hacks in wic, and that has to go in order to keep
> maintainability. We need to solve that differently, for sure.
> 
> > My suggestion is not to revert that. I agree with Henning that we
> > should cover that in CI. I'll provide an initial testing framework,
> > then we should sync who does what. The other mcopy and fsck issues
> > are not covered, either.
> > 
> > 
> > Regarding the PRoot PoC, I don't agree we are far away. Everything
> > works except mounting. We've just postponed the work due to
> > higher-prio issues.  
> 
> I'm happy to discuss the effort you see in resolving that last issue
> and will re-prioritize.
> 
> > 
> >   
> >>> b1511ec wic: Work around mcopy error  
> 
> This issue is not understood yet, thus the commit not ready for
> upstream. Furthermore, the log does not describe how to reproduce the
> issue. So - how to clarify if we still need it?

I can reproduce it when building images with directdisk.wks, i will
send patches for that.
The so-far supported sdimage-efi does not seem to be affected by it, at
least i never saw it failing.
This one, like the following is likely due to debian having different
versions of the tools than OE code might expect. And what is worse, we
are talking about host-tools here so Isar has to support a relatively
wide range.

> >>> 17f9196 wic: Introduce the `WicExecError` exception class  
> 
> Can you explain why fsck should return an error at all on a freshly
> built file system image? This seems to paper over some issue to me.

Debian simply uses an older version of e2sck, the bug has been fixed
upstream. I am guessing yocto must be using a more recent version.
The hack that "1" is on ok return value moved into wic_fakeroot.
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=bf9f3b6d5b10d19218b4ed904c12b22e36ec57dd



> >>>
> >>> All of them are not related to the bitbake core and fix concrete
> >>> issues with image generation that were not addressed in the
> >>> baseline bitbake. Did you address those issues in your new
> >>> changes?  
> >>
> >> Good points, should be clarified. Maybe an update of the upstream
> >> wic import is the answer if we are about to lose something. Better
> >> than patching locally in Isar, as so far.  
> > 
> > Do you mean we should initiate upstreaming that to OE? If yes, I
> > agree with you. The only question is point of time. My idea was to
> > wait till Henning completes the lifecycle with his OE contribution
> > and learn from his experience. If you think we should do that now,
> > please let me know.  
> 
> Local hacks can save some time for a while but will shoot back with
> more effort eventually. I think we are already at that point, so
> let's move forward. We can help you with this.
> 
> Jan
>