Re: [PATCH] image: include image name in the kernel/initrd image copies

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

Am Thu, 18 Oct 2018 12:29:47 +0200
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

> On 18.10.18 11:46, chombourger@gmail.com wrote:
> > 
> > Hi Jan,
> > 
> > See below
> > 
> > On Thursday, October 18, 2018 at 11:27:10 AM UTC+2, Jan Kiszka
> > wrote:
> > 
> >     On 18.10.18 11:04, Cedric Hombourger wrote:  
> >      > The kernel and initrd images are really image-specific
> >      > (especially the later with the initrd being created/updated
> >      > as packages get installed into the  
> >     root  
> >      > file-system). Make sure we retain a per-image copy of these
> >      > images in the  
> > 
> >     I don't buy this argument yet: Which additional parameters
> > besides the and the MACHINE make kernel different?
> > 
> > 
> > An image recipe may pull a different kernel than the default kernel
> > proposed by the MACHINE or DISTRO
> > There are several ways: locally setting KERNEL_NAME,
> > IMAGE_INSTALL_remove games, etc.
> > 
> > This is obviously a less frequent use-case than the initrd which is
> > evidently populated based on hooks/scripts installed into your root
> > file-system (and therefore image dependent)  
> 
> OK, in that light, it is something that should be called just like
> the generated image. But I think the whole beast needs rework now.
> See below.
> 
> > 
> >     If there is any, can't we associate that
> >     variation more directly with the image then? It's surely not
> > the image recipe name.
> > 
> > 
> > Would you have a suggestion (based on the extra info I provided
> > above)?
> > 
> > A possibly cleaner solution would be to NOT copy these files 
> > into DEPLOY_DIR_IMAGE in the first place! and have e.g. wic plugins
> > extract the kernel/initrd images from the rootfs they are working
> > with I am happy to rework this patch if breaking the API (by
> > removing KERNEL_IMAGE and INITRD_IMAGE) is an option  
> 
> We have two use cases so far: QEMU and wic. Both work without
> downstream effort by just using those two variables. That by itself
> is not bad. An alternative might only by peeking directly into the
> rootfs trees of the images, i.e. avoiding the copying to deploy. Not
> sure, actually, what value this copy-out provides, at least as long
> as the user does not manual deployment of the artifacts.

I think the only reason may be qemus --kernel and --initrd. Wic could
probably deal with the kernel being inside the rootfs, in the wic case
we even "ship" the files twice because /boot/ never gets cleaned.
But qemu is not able to look into an ext4img and the deploydir is the
only safe place to keep results.
If qemu is indeed the only reason, we should get rid of the copy and
change the ci-scripts to extract the ext4 for a temporary copy.

Henning

> Anyway. If we keep copy-out: Instead of appending further elements to
> the kernel/initrd prefix, we should really consolidate things. The
> image, maybe it be wic-generated or ext4-img or whatever, as well as
> associated artifacts should follow the same file naming scheme so
> that you can easily identify related artifacts.
> 
> Furthermore, we likely need to update things like 
> do_copy_boot_files[stamp-extra-info],
> do_populate_sdk[stamp-extra-info] to follow those patterns as well.
> 
> Jan
>