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

[Cedric Hombourger]

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
image deploy directory by inserting the name of the image (${PN}) into the
full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).

Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com>
---
meta/classes/image.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 05ff06f..c0af557 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -22,7 +22,8 @@ def get_image_name(d, name_link):
if os.path.exists(path_link):
base = os.path.basename(os.path.realpath(path_link))
full = base
- full += "_" + d.getVar("DISTRO", True)
+ full += "_" + d.getVar("PN", True)
+ full += "-" + d.getVar("DISTRO", True)
full += "-" + d.getVar("MACHINE", True)
return [base, full]
if os.path.islink(path_link):
--
2.11.0

[Jan Kiszka]

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? If there is any, can't we associate that
variation more directly with the image then? It's surely not the image recipe name.

> image deploy directory by inserting the name of the image (${PN}) into the
> full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).
>
> Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com>
> ---
> meta/classes/image.bbclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 05ff06f..c0af557 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -22,7 +22,8 @@ def get_image_name(d, name_link):
> if os.path.exists(path_link):
> base = os.path.basename(os.path.realpath(path_link))
> full = base
> - full += "_" + d.getVar("DISTRO", True)
> + full += "_" + d.getVar("PN", True)
> + full += "-" + d.getVar("DISTRO", True)
> full += "-" + d.getVar("MACHINE", True)
> return [base, full]
> if os.path.islink(path_link):
>

Jan

[chomb...@gmail.com]

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)

 

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

Cedric

 

[Jan Kiszka]

On 18.10.18 11:46, chomb...@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.

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

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[Jan Kiszka]

On 18.10.18 12:29, Jan Kiszka wrote:
> 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.

That last point is actually not an issue as the recipe name is included already,
and that extra-info make it unique in case the recipe does not carry any other
differentiating naming elements.

[chomb...@gmail.com]

Hi Jan,

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.

Same here, it just sounded like a bigger change (which I am happy to work on if we want to go down this path)

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.

Aren't we there with this patch?

$ ls *isar-image-base-debian-stretch-qemuamd64*

initrd.img-4.9.0-8-amd64_isar-image-base-debian-stretch-qemuamd64  isar-image-base-debian-stretch-qemuamd64.wic.img  vmlinuz-4.9.0-8-amd64_isar-image-base-debian-stretch-qemuamd6 

The command returned as expected all the image artifacts we have for IMAGE=isar-image-base && DISTRO=debian-stretch && MACHINE=qemuamd64

The name pattern would be: [<sub-image-name>-]<image>-<distro>-<machine>[<suffix>]

Cedric

[Jan Kiszka]

ext4-img does

EXT4_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.ext4.img"

wic-img does

WIC_IMAGE_FILE ="${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.wic.img"

Now I would expect something like

KERNEL_IMAGE = "${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.vmlinuz"

and similar for initrd. If there is a value (dunno), we could keep
including the kernel version.

Moreover, we should probably ensure via a single variable that the "${PN}-${DISTRO}-${MACHINE}" image name core is always the same, not
ad-hoc constructed in multiple places.

Or we strictly model what Yocto does, but that seems different to me
(bzImage--<kernel-recipe-version>-<machine>-<builddate>.bin), not even
multiconfig-ready.

[Cedric Hombourger]

The kernel and initrd images are really image-specific (especially the later

as the initrd is created/updated as packages get installed into the root

file-system). Make sure we retain a per-image copy of these images in the

image deploy directory by inserting the name of the image (${PN}) into the
full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).

In addition, an IMAGE_FULLNAME variable is introduced to combine the three
components of the image name: the (base) name of the image, the name of the
distribution and the name of the machine. This variable is now used in the
start_vm script and the image classes (image, ext4-img and wic-img).

Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com>
---

meta/classes/ext4-img.bbclass | 2 +-
meta/classes/image.bbclass | 7 ++++---
meta/classes/wic-img.bbclass | 6 +++---
3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta/classes/ext4-img.bbclass b/meta/classes/ext4-img.bbclass
index 78036a2..29e5f77 100644
--- a/meta/classes/ext4-img.bbclass
+++ b/meta/classes/ext4-img.bbclass
@@ -1,7 +1,7 @@
# This software is a part of ISAR.
# Copyright (C) 2015-2017 ilbers GmbH

-EXT4_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.ext4.img"
+EXT4_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${IMAGE_FULLNAME}.ext4.img"

do_ext4_image[stamp-extra-info] = "${DISTRO}-${MACHINE}"

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 05ff06f..ad19f3d 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -7,6 +7,9 @@ IMAGE_ROOTFS = "${WORKDIR}/rootfs"

IMAGE_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"

+# Name of the image including distro&machine names
+IMAGE_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
+
# These variables are used by wic and start_vm
KERNEL_IMAGE ?= "${@get_image_name(d, 'vmlinuz')[1]}"
INITRD_IMAGE ?= "${@get_image_name(d, 'initrd.img')[1]}"
@@ -21,9 +24,7 @@ def get_image_name(d, name_link):
path_link = os.path.join(S, name_link)

if os.path.exists(path_link):
base = os.path.basename(os.path.realpath(path_link))

- full = base

- full += "_" + d.getVar("DISTRO", True)

- full += "-" + d.getVar("MACHINE", True)
+ full = d.getVar("IMAGE_FULLNAME", True) + "." + base

return [base, full]
if os.path.islink(path_link):

return get_image_name(d, os.path.relpath(os.path.realpath(path_link),
diff --git a/meta/classes/wic-img.bbclass b/meta/classes/wic-img.bbclass
index d0747e2..e7527c8 100644
--- a/meta/classes/wic-img.bbclass
+++ b/meta/classes/wic-img.bbclass
@@ -63,7 +63,7 @@ addtask do_rootfs_wicenv after do_copy_boot_files before do_wic_image
do_rootfs_wicenv[vardeps] += "${WICVARS}"
do_rootfs_wicenv[prefuncs] = 'set_image_size'

-WIC_IMAGE_FILE ="${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.wic.img"
+WIC_IMAGE_FILE ="${DEPLOY_DIR_IMAGE}/${IMAGE_FULLNAME}.wic.img"

do_build[stamp-extra-info] = "${DISTRO}-${DISTRO_ARCH}"

@@ -81,10 +81,10 @@ do_wic_image() {
sudo -E chroot ${BUILDCHROOT_DIR} \
${ISARROOT}/scripts/wic create ${WKS_FULL_PATH} \
--vars "${STAGING_DIR}/${MACHINE}/imgdata/" \
- -o /tmp/${PN}-${DISTRO}-${MACHINE}.wic/ \
+ -o /tmp/${IMAGE_FULLNAME}.wic/ \
-e ${IMAGE_BASENAME} ${WIC_CREATE_EXTRA_ARGS}
sudo chown -R $(stat -c "%U" ${ISARROOT}) ${ISARROOT}/meta ${ISARROOT}/meta-isar ${ISARROOT}/scripts || true
- cp -f $(ls -t -1 ${BUILDCHROOT_DIR}/tmp/${PN}-${DISTRO}-${MACHINE}.wic/*.direct | head -1) ${WIC_IMAGE_FILE}
+ cp -f $(ls -t -1 ${BUILDCHROOT_DIR}/tmp/${IMAGE_FULLNAME}.wic/*.direct | head -1) ${WIC_IMAGE_FILE}
}

do_wic_image[file-checksums] += "${WKS_FULL_PATH}:True"
--
2.11.0

[cedric_h...@mentor.com]

Hi Jan,

Did you have a chance to look at v2?

Did I manage to address your initial review findings?

Thanks

Cedric

[Jan Kiszka]

On 22.10.18 13:49, cedric_h...@mentor.com wrote:
> Hi Jan,
>
> Did you have a chance to look at v2?
> Did I manage to address your initial review findings?

Sorry, we were/are busy for ELC-E preparations: On first sight, it looks good to me.

Just wondering: Do we want/need to document the renaming of kernel/initrd
somewhere, maybe in RECIPE-API-CHANGELOG.md?

Jan

>
> Thanks
> Cedric
>
> On Thursday, October 18, 2018 at 7:24:12 PM UTC+2, Cedric Hombourger wrote:
>
> The kernel and initrd images are really image-specific (especially the later
> as the initrd is created/updated as packages get installed into the root
> file-system). Make sure we retain a per-image copy of these images in the
> image deploy directory by inserting the name of the image (${PN}) into the
> full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).
>
> In addition, an IMAGE_FULLNAME variable is introduced to combine the three
> components of the image name: the (base) name of the image, the name of the
> distribution and the name of the machine. This variable is now used in the
> start_vm script and the image classes (image, ext4-img and wic-img).
>
> Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com

> <mailto:Cedric_H...@mentor.com>>

> --
> You received this message because you are subscribed to the Google Groups
> "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to isar-users+...@googlegroups.com
> <mailto:isar-users+...@googlegroups.com>.
> To post to this group, send email to isar-...@googlegroups.com
> <mailto:isar-...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/isar-users/d09c4a2f-4249-4914-9ceb-b5dfdf8924fa%40googlegroups.com
> <https://groups.google.com/d/msgid/isar-users/d09c4a2f-4249-4914-9ceb-b5dfdf8924fa%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Henning Schild]

I would suggest so make that two patches, one to introduce
IMAGE_FULLNAME and the actual change in the next.

Henning

Am Thu, 18 Oct 2018 19:23:56 +0200
schrieb Cedric Hombourger <Cedric_H...@mentor.com>:

[Henning Schild]

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

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

[Maxim Yu. Osipov]

Hi Cedric,

Are you going to send V3 of the patch to address Jan's and Henning's
suggestions to v2?

Kind regards,
Maxim.

Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mos...@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

[Cedric Hombourger]

Hi Maxim

Yes I will try to get to it today

Cedric

You received this message because you are subscribed to a topic in the Google Groups "isar-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/isar-users/_FHjvycAyeg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isar-users+...@googlegroups.com.
To post to this group, send email to isar-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/49365eab-5224-457b-271c-7e841eac08f3%40ilbers.de.

[Cedric Hombourger]

Hi Henning,

Are you suggesting that the first patch should define IMAGE_FULLNAME as ${DISTRO}-${MACHINE} and replace relevant occurrences of ${DISTRO}-${MACHINE} with ${IMAGE_FULLNAME}?

I am asking because it would no longer be the full name of the image but something more like a suffix; e.g.

EXT4_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.ext4.img”

would become

EXT4_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${PN}-${IMAGE_FULLNAME}.ext4.img"

I am happy to go ahead with this but it may be more confusing in the end

Cedric

-- 
You received this message because you are subscribed to a topic in the Google Groups "isar-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/isar-users/_FHjvycAyeg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isar-users+...@googlegroups.com.
To post to this group, send email to isar-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20181022172441.7eba0f77%40md1pvb1c.ad001.siemens.net.

[Henning Schild]

Am Thu, 25 Oct 2018 13:50:41 +0200
schrieb Cedric Hombourger <chomb...@gmail.com>:

> Hi Henning,
>
> Are you suggesting that the first patch should define IMAGE_FULLNAME
> as ${DISTRO}-${MACHINE} and replace relevant occurrences of
> ${DISTRO}-${MACHINE} with ${IMAGE_FULLNAME}?
>
> I am asking because it would no longer be the full name of the image
> but something more like a suffix; e.g.
>
> EXT4_IMAGE_FILE =
> "${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.ext4.img”
>
> would become
>
> EXT4_IMAGE_FILE =
> "${DEPLOY_DIR_IMAGE}/${PN}-${IMAGE_FULLNAME}.ext4.img"
>
> I am happy to go ahead with this but it may be more confusing in the
> end

Just wanted to propose a split, if you think it does not provide a
benefit just leave it the way it is.

Henning

> Cedric
>
> > On Oct 22, 2018, at 5:24 PM, Henning Schild
> > <henning...@siemens.com> wrote:
> >
> > I would suggest so make that two patches, one to introduce
> > IMAGE_FULLNAME and the actual change in the next.
> >
> > Henning
> >
> > Am Thu, 18 Oct 2018 19:23:56 +0200
> > schrieb Cedric Hombourger <Cedric_H...@mentor.com

> > <mailto:Cedric_H...@mentor.com>>:

> > <https://groups.google.com/d/topic/isar-users/_FHjvycAyeg/unsubscribe>.

> > To unsubscribe from this group and all its topics, send an email to
> > isar-users+...@googlegroups.com

> > <mailto:isar-users+...@googlegroups.com>. To post to this

> > group, send email to isar-...@googlegroups.com

> > <mailto:isar-...@googlegroups.com>. To view this discussion on

> > the web visit
> > https://groups.google.com/d/msgid/isar-users/20181022172441.7eba0f77%40md1pvb1c.ad001.siemens.net

> > <https://groups.google.com/d/msgid/isar-users/20181022172441.7eba0f77%40md1pvb1c.ad001.siemens.net>.

> > For more options, visit https://groups.google.com/d/optout

> > <https://groups.google.com/d/optout>.
>

[Cedric Hombourger]

The kernel and initrd images are really image-specific (especially the later
as the initrd is created/updated as packages get installed into the root
file-system). Make sure we retain a per-image copy of these images in the
image deploy directory by inserting the name of the image (${PN}) into the
full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).

In addition, an IMAGE_FULLNAME variable is introduced to combine the three
components of the image name: the (base) name of the image, the name of the
distribution and the name of the machine. This variable is now used in the
start_vm script and the image classes (image, ext4-img and wic-img).

Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com>
---

RECIPE-API-CHANGELOG.md | 24 ++++++++++++++++++++++++

meta/classes/ext4-img.bbclass | 2 +-
meta/classes/image.bbclass | 7 ++++---
meta/classes/wic-img.bbclass | 6 +++---

4 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
index 8d93ef4..c7b7552 100644
--- a/RECIPE-API-CHANGELOG.md
+++ b/RECIPE-API-CHANGELOG.md
@@ -3,6 +3,30 @@ Recipe API Changelog

Baseline: Release v0.5

+Upcoming changes (v0.7)
+-----------------------
+
+### more consistent artifact names
+
+multiconfig image artifacts are all placed in tmp/deploy/images. They include
+kernel, initrd and ext4/wic images. A consistent naming scheme is now used:
+`IMAGE-DISTRO-MACHINE.TYPE`. This scheme was already used for ext4/wic images
+so no visible changes there. Kernel and initrd images are however affected; for
+instance:
+
+```
+vmlinuz-4.9.0-8-armmp_debian-stretch-qemuarm
+```
+
+is now
+
+```
+isar-image-base-debian-stretch-qemuarm.vmlinuz-4.9.0-8-armmp
+```
+
+It should be noted that the `KERNEL_IMAGE` and `INITRD_IMAGE` variables were
+updated hence recipes using them shouldn't be impacted per se.
+
Changes in v0.6
---------------

2.11.0

[Maxim Yu. Osipov]

On 10/25/18 5:46 PM, Cedric Hombourger wrote:
> The kernel and initrd images are really image-specific (especially the later
> as the initrd is created/updated as packages get installed into the root
> file-system). Make sure we retain a per-image copy of these images in the
> image deploy directory by inserting the name of the image (${PN}) into the
> full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).
>
> In addition, an IMAGE_FULLNAME variable is introduced to combine the three
> components of the image name: the (base) name of the image, the name of the
> distribution and the name of the machine. This variable is now used in the
> start_vm script and the image classes (image, ext4-img and wic-img).

Applied to the 'next',

Regards,
Maxim.

[Jan Kiszka]

On 26.10.18 14:58, Maxim Yu. Osipov wrote:
> On 10/25/18 5:46 PM, Cedric Hombourger wrote:
>> The kernel and initrd images are really image-specific (especially the later
>> as the initrd is created/updated as packages get installed into the root
>> file-system). Make sure we retain a per-image copy of these images in the
>> image deploy directory by inserting the name of the image (${PN}) into the
>> full name of the artifacts (set in ${KERNEL_IMAGE} and ${INITRD_IMAGE}).
>>
>> In addition, an IMAGE_FULLNAME variable is introduced to combine the three
>> components of the image name: the (base) name of the image, the name of the
>> distribution and the name of the machine. This variable is now used in the
>> start_vm script and the image classes (image, ext4-img and wic-img).
>
> Applied to the 'next',

Just realized that we were trying to fix this issue at the wrong end. The proper
fix is doing what OE does:

DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"

Then we can revert this commit again.

Jan