Re: [PATCH] images: wic: limit use of sudo and enable manual call again

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

Am Thu, 1 Feb 2018 17:09:22 +0100
schrieb Baurzhan Ismagulov <ibr@radix50.net>:

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