From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6517147827419742208 X-Received: by 10.223.130.184 with SMTP id 53mr1650593wrc.6.1517406366740; Wed, 31 Jan 2018 05:46:06 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.129.141 with SMTP id c135ls1098261wmd.11.canary-gmail; Wed, 31 Jan 2018 05:46:06 -0800 (PST) X-Google-Smtp-Source: AH8x224qcCiBTzmzg6bFNm8QWtbJNGIMd98QIJjwyYl/qP27jQUCnhXYr3x22QH4VMbyCZc53aeL X-Received: by 10.223.156.210 with SMTP id h18mr3461047wre.1.1517406366296; Wed, 31 Jan 2018 05:46:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517406366; cv=none; d=google.com; s=arc-20160816; b=DxCaZCg7Y1nu1NNTCvRctkrtaxR3a7OJ9pRb41Hfv0I2aVCgEJiHSPzNFs1f3M9KS9 WxQ+bcGIMiYjjjN18LpKk2M5Agrtm0JtSeA2vR+5+y/tUbMWtps9fdrI9m/HiJomIHsP EHcXh/U2ihJQNbb3i2qo7GEKCNBrKS+FBgLGRFuhqA257Y4iXqdiPmGh5y4eZ4YRnCUp aImN/qfSrvIBphwXDXAulAW93cTedBxSvdgAaRDii3ze8oAXDalnj6i7SUzHwrqny26d lEevKY/Da1NpEg9GXTTD4RuBfBvEVLHJvDvcnscUQUumyUz7XivWBBDsZBA9zOHG7zKc BjHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=0wvXnOAIqIRBO4DHT04QMA2sO8j7JmcPaq9fI72O4s0=; b=NgBZWIFMWXp8VvXW5b68cKu8SIH5CKOB+TDesfBDSFEjm6zrYjElpgVPFQxDO13lL2 yWs/zOJUz/oaITVLRukNiYyx3jvu1FDur8tU2rlI+DZHgURCtkMKADm1aheDTKeL3zL0 lm/XISWR1JsVDFotrTouL3bokVGLdoW/2MkgHiAQ8tkB94eyMl+bMQ1cUrqso4qBqWsh dFyO6Bqs/GkO8RR7GeKwy5UtTVK/UzE5stUf1Pte22Kbt6cjkyq4sr+ojOq+JeT5kNFi AXQEd1T2fzo1yUZ9o/r3D8RrjlYFj9rf2/Jc+r7oAhoggvFYBNer/pHo1iDfRyw+YOmU EDyA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id k21si1630154wrd.1.2018.01.31.05.46.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 05:46:06 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w0VDk56u024159 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 31 Jan 2018 14:46:05 +0100 Received: from mmd1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w0VDk59T020776; Wed, 31 Jan 2018 14:46:05 +0100 Date: Wed, 31 Jan 2018 14:46:04 +0100 From: Henning Schild To: "[ext] Jan Kiszka" Cc: Subject: Re: [PATCH 0/9] first wic integration Message-ID: <20180131144604.2ed21a4e@mmd1pvb1c.ad001.siemens.net> In-Reply-To: <1a55fba5-e089-5bbe-4f14-e1931dea38dd@siemens.com> References: <20180131111253.49011346@mmd1pvb1c.ad001.siemens.net> <20180131112421.GA6508@yssyq.radix50.net> <675eeef9-1e24-4784-b894-4ce665da26fb@siemens.com> <20180131120245.GC6508@yssyq.radix50.net> <1a55fba5-e089-5bbe-4f14-e1931dea38dd@siemens.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: rXugiIIByiZl Am Wed, 31 Jan 2018 13:15:28 +0100 schrieb "[ext] Jan Kiszka" : > 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 >