Re: [PATCH 0/9] first wic integration

[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?

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

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

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux