Re: [PATCH 2/2] integrate ubifs image type

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

On Tue, 29 Jan 2019 09:24:38 +0100
Claudius Heine <claudius.heine.ext@siemens.com> wrote:

> On 29/01/2019 09.16, [ext] Claudius Heine wrote:
> >>>>> +do_ubifs_image[stamp-extra-info] = "${DISTRO}-${MACHINE}"
> >>>>> +
> >>>>> +# Generate ubifs filesystem image
> >>>>> +do_ubifs_image() {
> >>>>> +    rm -f ${DEPLOY_DIR_IMAGE}/${UBIFS_IMAGE_FILE}
> >>>>> +
> >>>>> +    buildchroot_do_mounts
> >>>>> +
> >>>>> +    sudo flock ${MOUNT_LOCKFILE} -c ' \
> >>>>> +        mkdir -p ${BUILDROOT_DEPLOY} ${BUILDROOT_ROOTFS}
> >>>>> +        mount --bind ${DEPLOY_DIR_IMAGE} ${BUILDROOT_DEPLOY}
> >>>>> +        mount --bind ${IMAGE_ROOTFS} ${BUILDROOT_ROOTFS}
> >>>>> +    '  
> >>>>
> >>>> I think this mounting should also be required by a proper ext4
> >>>> class. On the other hand the wic one moves the image into the
> >>>> final deploy folder.
> >>>> Not sure what is best but maybe a good idea to go for "always
> >>>> move" or "always mount".  
> >>>
> >>> Hmm.. In OE this task would not to touch the deploy directory and
> >>> *copy* all artifacts in a dedicated task AFAIK. But OE has a
> >>> completely different image creation pipeline and infrastructure
> >>> than isar, so who knows how things should be done here.  
> >>
> >> We currently generate and deploy in one task. The fun thing is
> >> that we need multiple commands and can probably end up in weird
> >> states if we get interrupted or fail.
> >>
> >> Changing that general pattern is a discussion of its own, since it
> >> would change the API.
> >>
> >> Staying in the current API i think the mount and generate directly
> >> into deploy ... no more chmod/chown mv ... whatever. Would be the
> >> cleanest way. We already have a reliable umount mechanism to clean
> >> up if things go wrong.
> >>
> >> If you agree: Please include that deploydir/rootfs mount into the
> >> common mounts and update your imager. I will do the same for wic
> >> and maybe ext4.  
> > 
> > Ok. Will do that.  
> 
> Hmmm... You mean mounts that are done by `buildchroot_do_mounts`? 
> Extending that function would cause deploydir and rootfs to be
> mounted for every recipe. `rootfs` doesn't make sense for normal
> recipes and mounting `deploydir` into every recipes workspace sound
> bad as well...

You are right, those should better not be mounted for every recipe.

> Maybe we would need a image specific mount function and then switch 
> every image type to this. But I guess that would be a feature on its
> own.

That might actually call for a changed task-chain for image-recipes.
Maybe do_deploy_deb should actually be do_deploy, with a deb and a
deploydir implementation.
Forget me not liking the extra mount and let us remember this one as an
item on the non-existing TODO list.

Henning

> Claudius
>