From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6517147827419742208 X-Received: by 10.223.171.193 with SMTP id s59mr3875232wrc.5.1517508613536; Thu, 01 Feb 2018 10:10:13 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.167.75 with SMTP id q72ls120430wme.0.gmail; Thu, 01 Feb 2018 10:10:13 -0800 (PST) X-Google-Smtp-Source: AH8x227NByHI4ySrWyX0E4Nb3um0BEbi/3hgt9MK6DFf4VIXJowMKnY/ebSfJnKgxwS3IlXUA7YR X-Received: by 10.28.89.193 with SMTP id n184mr3913407wmb.22.1517508613071; Thu, 01 Feb 2018 10:10:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517508613; cv=none; d=google.com; s=arc-20160816; b=KGUjWFnvf8ldKzyqF4YwC2ZkjY5aMeibSM/eqXviIz0TPAs8Z8pSrIz0amMijYgkdS YWe0sb6ZGmxVwow+TVsbIeRnTf53dkMtgsNRK/vzQ/0nIxYfGTN34vjGlSwCCjmRNqSo ro62sNIgj8lyJov/CdjVboLCUATVgr9gLn0vzm2g0dR9jpafu4zcdnFzw5EkKpH5K3Y5 H8T6Pb1cgbHBs7IKS7pBussLoOnm1PC5RTzbfkw1OpVB0WUCqJD0K8JL38yn0hQBUQyZ LuhFQmX61AVHM/YUxtEP1KNNODvId7N9Yk8oG/Ba8gk5GyeMizU0VjtVOYnXb4vITIhv J7TQ== 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=B3NvxRCRq5iEjT6Q/LnwZOCo37GrHkAs5P4RuVlNUp4=; b=tRwna6E2E+CkZVo+xJqjJh0WdHCfoHnya2XjrnlF6SlXE+m/NNP7b/xz5svHcjqczs aeiuZXYyCreoaRNfN3VOPfM9MD2De2m20N70hUkEshhbdYGKpk47pG2ScL/d/ZRcaqGH bF4JkOu1XH6+Uc0noDYO6Jh7uVOPfBmKYeioI3Ko6ka50dEGFdq1wWQvjrnZUeMGLCpH LnByP94w46z5nRyo4o/HkzJVmeEfbAX1kvawvGGWj/wzUeT6wHbGL01H+n58kEJlpmhp 17b8Gmh495gbQAFsuxtFvP0vyXYP69UFNwxcIBXM0TBXLg8RWvroarRn+igfAganOquj qTDw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id g70si142359wmc.3.2018.02.01.10.10.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 10:10:13 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w11IAC6L019426 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Feb 2018 19:10:12 +0100 Received: from mmd1pvb1c.ad001.siemens.net ([167.87.78.7]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w11IACjb021058; Thu, 1 Feb 2018 19:10:12 +0100 Date: Thu, 1 Feb 2018 19:10:29 +0100 From: Henning Schild To: Baurzhan Ismagulov Cc: Subject: Re: [PATCH] images: wic: limit use of sudo and enable manual call again Message-ID: <20180201191029.24608f9f@mmd1pvb1c.ad001.siemens.net> In-Reply-To: <20180201160922.GA4056@yssyq.radix50.net> References: <20180201124106.29397-1-henning.schild@siemens.com> <20180201134459.319ab24f@mmd1pvb1c.ad001.siemens.net> <20180201160922.GA4056@yssyq.radix50.net> 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: 4sknLYsTmaDw Am Thu, 1 Feb 2018 17:09:22 +0100 schrieb Baurzhan Ismagulov : > On Thu, Feb 01, 2018 at 01:44:59PM +0100, Henning Schild wrote: > > This patch addresses the two main issues found in the reviews. The > > big "sudo" and the broken "call it manually". The latter one is not > > fully solved because users will have to call "isar-wic" instead of > > "wic". > > > > I would even suggest to not fold this into the series and apply it > > on top. It kind of shows some of the hacks required to wrap an > > unmodified wic. The patch cleanly applies on top of the series i > > posted so far. > > Wow, that's an interesting approach, thanks for the effort. Splitting > wic and isar-wic reduces user surprise, which would be a good thing. Since i wanted wic to stay untouched i had to introduce isar-wic to wrap it. It prepares some of the hacks we need in Isar, that code got moved out of the bbclass into isar-wic. > Do I understand correctly, you replace du and mkfs.* with your own > versions and execute the respective command with superuser > privileges? Let me read the code in more detail, but if yes, I'm not > sure the complexity is worth the use case. "du" and "mkfs" are symlinks to "isar-wic-handler". They are placed in PATH before the real ones so wic calls end up in the handler. The handler just executes them under sudo. The other thing the handler does is act as fakeroot cmd where it does not bail out on ret "1" from fsck. Both hacks that where previously in wic. > I haven't finished reading the first series yet. Some background > questions: > > 1. Are there any disadvantages of using wic, compared to the > old-school ext4-img? That is still available as image type, however wic has the potential to replace that eventually. As far as i understood wic builds disks not partitions and ext4 builds a partition only. > 2. AFAICT, Yocto still maintains both wic and image-types.bbclass. > Why don't they move to wic completely? I think because of disk vs. partition. You can build a disk with just one partition and use the intermediate file as output, but i think our wic version does not support that. My guess is partitions where there before wic and nobody cared to clean up. And there might be image types that wic can not do i.e. tarball > 3. With wic-img.bbclass, how does one choose fs type? E.g., quickly > generate the same image on ext4 and ext3. You could write an image like that one: > IMAGE_TYPE = 'wic-img' > require recipes-core/images/isar-image-base.bb > WKS_FILE = "sdimage-efi" or with the other patch i sent > WKS_FILE = "directdisk-isar" For i.e. ext3 just copy the wks file and change the fstype in there. You could move sdimage-efi.wks to sdimage-efi-ext3.wks > 4. How to add a new fs type to wic? This can be done with a wic plugin in any layer. Ideally one should think whether this should be an upstream wic patch, submit it and eventually update wic in Isar. But this is more a wic-question, not really an Isar one. > I see that you add wic-img.bbclass, but no image uses it. Would it be > useful to migrate all images to wic, remove ext4-img, and remove wic > usage from the docs? If that solution would be "clean" and we have > answers to the questions above, I could possibly live with all-in > sudo, although I'd still prefer keeping the sudo hack for a while. True, i did not explain how to test this. Please refer to the example i gave above. For moving all images to wic, that sounds like a tempting idea. But that needs more work. 1. the question of partitions vs. disks, as i said an update of wic could potentially help here, because you can write in your wks that you want to keep the partition images ... or a disk-plugin that can handle exactly one partition and does not try to add bootloader/disk stuff 2. the image file names are generated from wks-file-name, date, disk-plugin-name and they do not contain all the exta-stamps to play well with multiconfig ... i would be happy to assign this one to people that insist on that complexity ;) btw. all the kernels and initrds that currently end up in the deploy/images have issues there as well Next thing on my plate would be to make wic fetch its artifacts only from buildchroot or rootfs. sdimage-efi actually installs the bootloader from the host into the target! And enable legacy bios images, a first patch was already sent. wic plugins that deal with bootloaders very much depend on the way there where installed, and debian installs them not the same way OE does. So these plugins need to get forked. For dropping manual calls to wic and removing it from the docs: I made some effort to keep manual wic-usage, it has its value for devs that might want to create multiple images from one rootfs probaly also users. I would like to keep that. Coming up with this version was a lot of trial and error. If it ends up being not maintainable or causes trouble we can go back to the big sudo. For the series and this patch i would like to ask wic-users to try it out and give feedback. Once wic plays well with multiconfig we can integrate it into the default builds and CI. Henning > With kind regards, > Baurzhan. >