| Message ID | 20240207102529.128369-1-matthias.schiffer@ew.tq-group.com |
|---|---|
| State | New |
| Headers | show |
| Series | kernel.bbclass: install .config to deploy dir | expand |
On Wed, Feb 7, 2024 at 5:26 AM Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote: > > Deploy the kernel configuration with the built images, so it is easy to > check its contents, or rebuild the same configuration outside of the > Yocto build system. > I'm not convinced we need yet more clutter in the deploy directory, but at a minimum, this patch also needs an update to the documentation (apologies if I missed it on the docs list). One could argue that the config could be pulled out of the other packages and artifacts, and that it wouldn't be recommended to use that config for rebuilding outside of yocto, as we aren't providing the matching sources in the deploy directory. I would also be nice in the commit log to indicate how cleanup of the deploydir has been tested to show that we won't end up with config* files and links in the directory after their associated images have been removed. (I haven't looked at the deploy classes in quite some time, so I'm unsure if anything in particular needs to be done). Bruce > This can be particularly convenient when running a Yocto build as a CI > job, and only the deploy dir is made available for download. > > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> > --- > meta/classes-recipe/kernel-artifact-names.bbclass | 3 +++ > meta/classes-recipe/kernel.bbclass | 7 +++++++ > 2 files changed, 10 insertions(+) > > diff --git a/meta/classes-recipe/kernel-artifact-names.bbclass b/meta/classes-recipe/kernel-artifact-names.bbclass > index 1a7611a15e..8e2ef0d627 100644 > --- a/meta/classes-recipe/kernel-artifact-names.bbclass > +++ b/meta/classes-recipe/kernel-artifact-names.bbclass > @@ -16,6 +16,9 @@ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}${IMAGE_MACHINE_SUFFIX}${IMAGE_V > KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" > KERNEL_ARTIFACT_BIN_EXT ?= ".bin" > > +KERNEL_CONFIG_NAME ?= "${KERNEL_ARTIFACT_NAME}" > +KERNEL_CONFIG_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" > + > KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" > KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" > KERNEL_IMAGE_BIN_EXT ?= "${KERNEL_ARTIFACT_BIN_EXT}" > diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass > index a76aaee5ba..8a98899e04 100644 > --- a/meta/classes-recipe/kernel.bbclass > +++ b/meta/classes-recipe/kernel.bbclass > @@ -812,6 +812,13 @@ kernel_do_deploy() { > mkdir "$deployDir" > fi > > + if [ -n "${KERNEL_CONFIG_NAME}" ]; then > + install -m 0644 .config $deployDir/config-${KERNEL_CONFIG_NAME} > + if [ -n "${KERNEL_CONFIG_LINK_NAME}" ]; then > + ln -sf config-${KERNEL_CONFIG_NAME} $deployDir/config-${KERNEL_CONFIG_LINK_NAME} > + fi > + fi > + > for imageType in ${KERNEL_IMAGETYPES} ; do > baseName=$imageType-${KERNEL_IMAGE_NAME} > > -- > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany > Amtsgericht München, HRB 105018 > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider > https://www.tq-group.com/ > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#195047): https://lists.openembedded.org/g/openembedded-core/message/195047 > Mute This Topic: https://lists.openembedded.org/mt/104215836/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
On Wed, 2024-02-07 at 12:42 +0000, Bruce Ashfield wrote: > ******************** > Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie wissen, dass diese aus einer sicheren Quelle stammen und sicher sind. Leiten Sie die E-Mail im Zweifelsfall zur Prüfung an den IT-Helpdesk weiter. > Attention external email: Open attachments and links only if you know that they are from a secure source and are safe. In doubt forward the email to the IT-Helpdesk to check it. > ******************** > > On Wed, Feb 7, 2024 at 5:26 AM Matthias Schiffer > <matthias.schiffer@ew.tq-group.com> wrote: > > > > Deploy the kernel configuration with the built images, so it is easy to > > check its contents, or rebuild the same configuration outside of the > > Yocto build system. > > > > I'm not convinced we need yet more clutter in the deploy directory, but > at a minimum, this patch also needs an update to the documentation > (apologies if I missed it on the docs list). Sorry about the missing docs, I'll provide a patch for that as well. > > One could argue that the config could be pulled out of the other > packages and artifacts, and that it wouldn't be recommended to > use that config for rebuilding outside of yocto, as we aren't providing > the matching sources in the deploy directory. There are at least some cases where the config can't be pulled out of anything else - without CONFIG_IKCONFIG, the config is not embedded in the built kernel images. In constrained environments, it may be desirable to disable such options to reduce the kernel size. As a data point from other distros, Debian/Ubuntu disable CONFIG_IKCONFIG and instead provide the config next to the kernel images in /boot. > > I would also be nice in the commit log to indicate how cleanup of the > deploydir has been tested to show that we won't end up with config* > files and links in the directory after their associated images have been > removed. (I haven't looked at the deploy classes in quite some time, > so I'm unsure if anything in particular needs to be done). My understanding is that unclean deploy dir issues are pretty much a thing of the past, as deploy.bbclass sets `do_deploy[cleandirs] = "${DEPLOYDIR}"` (so do_deploy always starts with a pristine destination directory), and the sstate tracking takes care of the rest. Thanks, Matthias > > Bruce > > > > > This can be particularly convenient when running a Yocto build as a CI > > job, and only the deploy dir is made available for download. > > > > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> > > --- > > meta/classes-recipe/kernel-artifact-names.bbclass | 3 +++ > > meta/classes-recipe/kernel.bbclass | 7 +++++++ > > 2 files changed, 10 insertions(+) > > > > diff --git a/meta/classes-recipe/kernel-artifact-names.bbclass b/meta/classes-recipe/kernel-artifact-names.bbclass > > index 1a7611a15e..8e2ef0d627 100644 > > --- a/meta/classes-recipe/kernel-artifact-names.bbclass > > +++ b/meta/classes-recipe/kernel-artifact-names.bbclass > > @@ -16,6 +16,9 @@ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}${IMAGE_MACHINE_SUFFIX}${IMAGE_V > > KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" > > KERNEL_ARTIFACT_BIN_EXT ?= ".bin" > > > > +KERNEL_CONFIG_NAME ?= "${KERNEL_ARTIFACT_NAME}" > > +KERNEL_CONFIG_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" > > + > > KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" > > KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" > > KERNEL_IMAGE_BIN_EXT ?= "${KERNEL_ARTIFACT_BIN_EXT}" > > diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass > > index a76aaee5ba..8a98899e04 100644 > > --- a/meta/classes-recipe/kernel.bbclass > > +++ b/meta/classes-recipe/kernel.bbclass > > @@ -812,6 +812,13 @@ kernel_do_deploy() { > > mkdir "$deployDir" > > fi > > > > + if [ -n "${KERNEL_CONFIG_NAME}" ]; then > > + install -m 0644 .config $deployDir/config-${KERNEL_CONFIG_NAME} > > + if [ -n "${KERNEL_CONFIG_LINK_NAME}" ]; then > > + ln -sf config-${KERNEL_CONFIG_NAME} $deployDir/config-${KERNEL_CONFIG_LINK_NAME} > > + fi > > + fi > > + > > for imageType in ${KERNEL_IMAGETYPES} ; do > > baseName=$imageType-${KERNEL_IMAGE_NAME} > > > > -- > > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany > > Amtsgericht München, HRB 105018 > > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider > > https://www.tq-group.com/ > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#195047): https://lists.openembedded.org/g/openembedded-core/message/195047 > > Mute This Topic: https://lists.openembedded.org/mt/104215836/1050810 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > > -=-=-=-=-=-=-=-=-=-=-=- > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II >
Hi, On Wed, Feb 07, 2024 at 02:14:33PM +0100, Matthias Schiffer wrote: > On Wed, 2024-02-07 at 12:42 +0000, Bruce Ashfield wrote: > > On Wed, Feb 7, 2024 at 5:26 AM Matthias Schiffer > > <matthias.schiffer@ew.tq-group.com> wrote: > > > > > > Deploy the kernel configuration with the built images, so it is easy to > > > check its contents, or rebuild the same configuration outside of the > > > Yocto build system. > > > > > > > I'm not convinced we need yet more clutter in the deploy directory, but > > at a minimum, this patch also needs an update to the documentation > > (apologies if I missed it on the docs list). > > Sorry about the missing docs, I'll provide a patch for that as well. > > > > > One could argue that the config could be pulled out of the other > > packages and artifacts, and that it wouldn't be recommended to > > use that config for rebuilding outside of yocto, as we aren't providing > > the matching sources in the deploy directory. > > There are at least some cases where the config can't be pulled out of anything else - without > CONFIG_IKCONFIG, the config is not embedded in the built kernel images. In constrained environments, > it may be desirable to disable such options to reduce the kernel size. > > As a data point from other distros, Debian/Ubuntu disable CONFIG_IKCONFIG and instead provide the > config next to the kernel images in /boot. Check the kernel-dev package. The config is there. > > > > I would also be nice in the commit log to indicate how cleanup of the > > deploydir has been tested to show that we won't end up with config* > > files and links in the directory after their associated images have been > > removed. (I haven't looked at the deploy classes in quite some time, > > so I'm unsure if anything in particular needs to be done). > > My understanding is that unclean deploy dir issues are pretty much a thing of the past, as > deploy.bbclass sets `do_deploy[cleandirs] = "${DEPLOYDIR}"` (so do_deploy always starts with > a pristine destination directory), and the sstate tracking takes care of the rest. I agree that deploy directories have way too many things already. And recipes often get it wrong trying to pass files through it from providers to users without setting task dependendencies and sstate caching correctly. Cheers, -Mikko
On Wed, Feb 7, 2024 at 8:33 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote: > > Hi, > > On Wed, Feb 07, 2024 at 02:14:33PM +0100, Matthias Schiffer wrote: > > On Wed, 2024-02-07 at 12:42 +0000, Bruce Ashfield wrote: > > > On Wed, Feb 7, 2024 at 5:26 AM Matthias Schiffer > > > <matthias.schiffer@ew.tq-group.com> wrote: > > > > > > > > Deploy the kernel configuration with the built images, so it is easy to > > > > check its contents, or rebuild the same configuration outside of the > > > > Yocto build system. > > > > > > > > > > I'm not convinced we need yet more clutter in the deploy directory, but > > > at a minimum, this patch also needs an update to the documentation > > > (apologies if I missed it on the docs list). > > > > Sorry about the missing docs, I'll provide a patch for that as well. > > > > > > > > One could argue that the config could be pulled out of the other > > > packages and artifacts, and that it wouldn't be recommended to > > > use that config for rebuilding outside of yocto, as we aren't providing > > > the matching sources in the deploy directory. > > > > There are at least some cases where the config can't be pulled out of anything else - without > > CONFIG_IKCONFIG, the config is not embedded in the built kernel images. In constrained environments, > > it may be desirable to disable such options to reduce the kernel size. Not replying to Mikko, but to Matthias for this comment below (I thought I'd save us an email by doing both at once). On this point, I am well versed in what we can and can't do with the config embedded into the kernel and related size concerns. So I did consider them in my reply. My point is, that is a CI system wants to look something like this up, I'm happy to push the requirement to provide that information to whoever is configuring and building the kernel, versus putting another file into deploy for everyone who builds a kernel (or duplicating information we have elsewhere already). > > > > As a data point from other distros, Debian/Ubuntu disable CONFIG_IKCONFIG and instead provide the > > config next to the kernel images in /boot. > > Check the kernel-dev package. The config is there. > This was also my first thought. Just save that package and use the config from there. At least we know it is curated and in sync. > > > > > > I would also be nice in the commit log to indicate how cleanup of the > > > deploydir has been tested to show that we won't end up with config* > > > files and links in the directory after their associated images have been > > > removed. (I haven't looked at the deploy classes in quite some time, > > > so I'm unsure if anything in particular needs to be done). > > > > My understanding is that unclean deploy dir issues are pretty much a thing of the past, as > > deploy.bbclass sets `do_deploy[cleandirs] = "${DEPLOYDIR}"` (so do_deploy always starts with > > a pristine destination directory), and the sstate tracking takes care of the rest. > > I agree that deploy directories have way too many things already. And recipes often get it wrong trying > to pass files through it from providers to users without setting task dependendencies and sstate caching > correctly. And we have the kernel shared artifacts dir, which can be saved / copied if a later stage in a pipeline needs the information. I too have seen issues with sstate and the cleanup restoring (or not) files that I'd expect. But have never made it reproducible enough to debug. In the end, I'd leave this up to RP as he likely has a better global view of the deploy directory and if adding another file is acceptable. The minium needed in a v2 would to indicate that the docs update will be done. Bruce > Cheers, > > -Mikko
On 7 Feb 2024, at 10:25, Matthias Schiffer via lists.openembedded.org <matthias.schiffer=ew.tq-group.com@lists.openembedded.org> wrote: > > Deploy the kernel configuration with the built images, so it is easy to > check its contents, or rebuild the same configuration outside of the > Yocto build system. For what it's worth, I added a task quite recently to tell you where the config file is (and generate it, if needed), so for “what did this kernel I just built have as the config” that is potentially more useful than deploying as it works even when the compile fails, or if it hasn’t finished yet: $ bitbake virtual/kernel -c showconfig … Config file written to /yocto/ross/build/tmp/work/qemuarm64-poky-linux/linux-yocto/6.6.12+git/linux-qemuarm64-standard-build/.config > This can be particularly convenient when running a Yocto build as a CI > job, and only the deploy dir is made available for download. I’m wondering if the kernel-dev package should split the config out into a subpackage, so it can be installed or examined separately. Ross
On Wed, 2024-02-07 at 15:58 +0000, Ross Burton wrote: > ******************** > Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie wissen, dass diese aus einer sicheren Quelle stammen und sicher sind. Leiten Sie die E-Mail im Zweifelsfall zur Prüfung an den IT-Helpdesk weiter. > Attention external email: Open attachments and links only if you know that they are from a secure source and are safe. In doubt forward the email to the IT-Helpdesk to check it. > ******************** > > On 7 Feb 2024, at 10:25, Matthias Schiffer via lists.openembedded.org <matthias.schiffer=ew.tq-group.com@lists.openembedded.org> wrote: > > > > Deploy the kernel configuration with the built images, so it is easy to > > check its contents, or rebuild the same configuration outside of the > > Yocto build system. > > For what it's worth, I added a task quite recently to tell you where the config file is (and generate it, if needed), so for “what did this kernel I just built have as the config” that is potentially more useful than deploying as it works even when the compile fails, or if it hasn’t finished yet: > > $ bitbake virtual/kernel -c showconfig > … > Config file written to /yocto/ross/build/tmp/work/qemuarm64-poky-linux/linux-yocto/6.6.12+git/linux-qemuarm64-standard-build/.config Hmm, I *think* this will not help our particular usecase, as our CI jobs always run with `INHERIT += "rm_work"`, so I'd assume that the kernel build dir is deleted between bitbake calls - but I might be wrong about the exact point where "rm_work" runs. > > > > This can be particularly convenient when running a Yocto build as a CI > > job, and only the deploy dir is made available for download. > > I’m wondering if the kernel-dev package should split the config out into a subpackage, so it can be installed or examined separately. In any case, we can update our CI to save the kernel-dev package or its contents, so I'm fine with this patch being dropped. Thanks! Regards, Matthias
Hi Matthias, Matthias Schiffer <matthias.schiffer@ew.tq-group.com> escreveu (quinta, 8/02/2024 à(s) 08:50): > On Wed, 2024-02-07 at 15:58 +0000, Ross Burton wrote: > > ******************** > > Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie > wissen, dass diese aus einer sicheren Quelle stammen und sicher sind. > Leiten Sie die E-Mail im Zweifelsfall zur Prüfung an den IT-Helpdesk weiter. > > Attention external email: Open attachments and links only if you know > that they are from a secure source and are safe. In doubt forward the email > to the IT-Helpdesk to check it. > > ******************** > > > > On 7 Feb 2024, at 10:25, Matthias Schiffer via lists.openembedded.org > <matthias.schiffer=ew.tq-group.com@lists.openembedded.org> wrote: > > > > > > Deploy the kernel configuration with the built images, so it is easy to > > > check its contents, or rebuild the same configuration outside of the > > > Yocto build system. > > > > For what it's worth, I added a task quite recently to tell you where the > config file is (and generate it, if needed), so for “what did this kernel I > just built have as the config” that is potentially more useful than > deploying as it works even when the compile fails, or if it hasn’t finished > yet: > > > > $ bitbake virtual/kernel -c showconfig > > … > > Config file written to > /yocto/ross/build/tmp/work/qemuarm64-poky-linux/linux-yocto/6.6.12+git/linux-qemuarm64-standard-build/.config > > Hmm, I *think* this will not help our particular usecase, as our CI jobs > always run with `INHERIT += > "rm_work"`, so I'd assume that the kernel build dir is deleted between > bitbake calls - but I might > be wrong about the exact point where "rm_work" runs. > The kernel sources and build artifacts are particular on this aspect and were placed on a work-shared dir tmp/work-shared/MACHINE, more specifically kernel-source and kernel-build-artifacts . Anyway any recipe that inherits the kernel bbclass was excluded to be removed by the rm_works, this can be checked on the meta/classes/rm_work.bbclass inject_rm_work python function. Jose > > > > > > > This can be particularly convenient when running a Yocto build as a CI > > > job, and only the deploy dir is made available for download. > > > > I’m wondering if the kernel-dev package should split the config out into > a subpackage, so it can be installed or examined separately. > > In any case, we can update our CI to save the kernel-dev package or its > contents, so I'm fine with > this patch being dropped. Thanks! > > Regards, > Matthias > > > -- > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany > Amtsgericht München, HRB 105018 > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider > https://www.tq-group.com/ > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#195120): > https://lists.openembedded.org/g/openembedded-core/message/195120 > Mute This Topic: https://lists.openembedded.org/mt/104215836/5052612 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > quaresma.jose@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On 07.02.24 11:25, Matthias Schiffer via lists.openembedded.org wrote: > Deploy the kernel configuration with the built images, so it is easy to > check its contents, or rebuild the same configuration outside of the > Yocto build system. Isn't the kernel already in the -dev package included? From a security point of view I wouldn't welcome the inclusion in the main package, because the config should not be deployed by default. The config contains many information about the available code in the kernel, which an attacker can only guess otherwise. Kind regards Jörg Sommer
On 08/02/2024 14:54:49+0100, J�rg Sommer via lists.openembedded.org wrote: > On 07.02.24 11:25, Matthias Schiffer via lists.openembedded.org wrote: > > Deploy the kernel configuration with the built images, so it is easy to > > check its contents, or rebuild the same configuration outside of the > > Yocto build system. > > Isn't the kernel already in the -dev package included? > > From a security point of view I wouldn't welcome the inclusion in the > main package, because the config should not be deployed by default. The > config contains many information about the available code in the kernel, > which an attacker can only guess otherwise. However, as per the GPL, you will have to provide the kernel configuration to the recipients of the product upon request which can be any attacker.
On 09.02.24 00:16, Alexandre Belloni wrote: > On 08/02/2024 14:54:49+0100, Jörg Sommer via lists.openembedded.org wrote: >> On 07.02.24 11:25, Matthias Schiffer via lists.openembedded.org wrote: >>> Deploy the kernel configuration with the built images, so it is easy to >>> check its contents, or rebuild the same configuration outside of the >>> Yocto build system. >> >> Isn't the kernel already in the -dev package included? >> >> From a security point of view I wouldn't welcome the inclusion in the >> main package, because the config should not be deployed by default. The >> config contains many information about the available code in the kernel, >> which an attacker can only guess otherwise. > > However, as per the GPL, you will have to provide the kernel > configuration to the recipients of the product upon request which can be > any attacker. But that's upon request. That raises the bar for an attacker and doesn't delivers all information for free. Kind regards Jörg Sommer
diff --git a/meta/classes-recipe/kernel-artifact-names.bbclass b/meta/classes-recipe/kernel-artifact-names.bbclass index 1a7611a15e..8e2ef0d627 100644 --- a/meta/classes-recipe/kernel-artifact-names.bbclass +++ b/meta/classes-recipe/kernel-artifact-names.bbclass @@ -16,6 +16,9 @@ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}${IMAGE_MACHINE_SUFFIX}${IMAGE_V KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" KERNEL_ARTIFACT_BIN_EXT ?= ".bin" +KERNEL_CONFIG_NAME ?= "${KERNEL_ARTIFACT_NAME}" +KERNEL_CONFIG_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" KERNEL_IMAGE_BIN_EXT ?= "${KERNEL_ARTIFACT_BIN_EXT}" diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass index a76aaee5ba..8a98899e04 100644 --- a/meta/classes-recipe/kernel.bbclass +++ b/meta/classes-recipe/kernel.bbclass @@ -812,6 +812,13 @@ kernel_do_deploy() { mkdir "$deployDir" fi + if [ -n "${KERNEL_CONFIG_NAME}" ]; then + install -m 0644 .config $deployDir/config-${KERNEL_CONFIG_NAME} + if [ -n "${KERNEL_CONFIG_LINK_NAME}" ]; then + ln -sf config-${KERNEL_CONFIG_NAME} $deployDir/config-${KERNEL_CONFIG_LINK_NAME} + fi + fi + for imageType in ${KERNEL_IMAGETYPES} ; do baseName=$imageType-${KERNEL_IMAGE_NAME}
Deploy the kernel configuration with the built images, so it is easy to check its contents, or rebuild the same configuration outside of the Yocto build system. This can be particularly convenient when running a Yocto build as a CI job, and only the deploy dir is made available for download. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> --- meta/classes-recipe/kernel-artifact-names.bbclass | 3 +++ meta/classes-recipe/kernel.bbclass | 7 +++++++ 2 files changed, 10 insertions(+)