Re: [isar-cip-core][PATCH 1/2] kas/opt: Add option for not install kernel

[Jan Kiszka <jan.kiszka@siemens.com>]

On 05.03.25 05:45, nobuhiro1.iwamatsu@toshiba.co.jp wrote:
> Hi Jan,
> 
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> Sent: Saturday, March 1, 2025 12:40 AM
>> To: iwamatsu nobuhiro(岩松 信洋 ○ＤＩＴＣ□ＤＩＴ○ＯＳＴ)
>> <nobuhiro1.iwamatsu@toshiba.co.jp>; cip-dev@lists.cip-project.org
>> Subject: Re: [isar-cip-core][PATCH 1/2] kas/opt: Add option for not install
>> kernel
>>
>> On 28.02.25 13:46, Nobuhiro Iwamatsu wrote:
>>> This adds an option to create an image that does not contain the kernel.
>>>
>>
>> What is the use case? How does this relate to kas/opt/kernelci.yml?
>>
> 
> This is not related kas/opt/kernelci.yml. This will be used to create rootfs for CIP/LAVA testing. 
> The current recipe creates an image containing the kernel binary. Kernel binaries are not needed in
> rootfs for kernel testing. Therefore, we have added an option to remove it.
> This is also useful because some users may need rootfs without kernel binaries.

For my understanding: When is kernelci.yml used, when the kernel-free
image? For kernelci, we also deploy (not right now as upstream's API is
changing), but that was always with the kernel - why there?

> 
>>> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
>>> ---
>>>  .gitlab-ci.yml             | 28 ++++++++++++++++++++++-
>>>  kas/opt/no_kernel.yml      | 17 ++++++++++++++
>>>  scripts/deploy-cip-core.sh | 47
>>> +++++++++++++++++++++++++++-----------
>>>  3 files changed, 78 insertions(+), 14 deletions(-)  create mode
>>> 100644 kas/opt/no_kernel.yml
>>>
>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 4df521b..a09eedd
>>> 100644
>>> --- a/.gitlab-ci.yml
>>> +++ b/.gitlab-ci.yml
>>> @@ -27,6 +27,7 @@ variables:
>>>    build_swu_v2: disable
>>>    swupdate_version: default
>>>    test_function: swupdate
>>> +  no_kernel: disable
>>>
>>>  stages:
>>>    - build
>>> @@ -67,9 +68,10 @@ default:
>>>      - if [ "${watchdog}" = "disable" ]; then
>> base_yaml="${base_yaml}:kas/opt/disable-watchdog.yml"; fi
>>>      - if [ "${security_test}" = "enable" ]; then
>> base_yaml="${base_yaml}:kas/opt/security_test.yml"; fi
>>>      - if [ "${swupdate_version}" = "2022.12" ]; then
>>> base_yaml="${base_yaml}:kas/opt/swupdate-2022.12.yaml"; fi
>>> +    - if [ "${no_kernel}" = "enable" ]; then
>>> + base_yaml="${base_yaml}:kas/opt/no_kernel.yml"; fi
>>>      - echo "Building ${base_yaml}"
>>>      - kas build ${base_yaml}
>>> -    - if [ "${deploy}" = "enable" ]; then scripts/deploy-cip-core.sh
>> ${release} ${target} ${extension} ${dtb} ${CI_COMMIT_REF_SLUG} wic; fi
>>> +    - if [ "${deploy}" = "enable" ]; then scripts/deploy-cip-core.sh
>>> + ${release} ${target} ${extension} ${no_kernel} ${dtb}
>>> + ${CI_COMMIT_REF_SLUG} wic; fi
>>>      - if [ "${build_swu_v2}" = "enable" ]; then
>>>            mkdir build/previous-image;
>>>            if [ "${extension}" = "security" ] || [ "${extension}" =
>>> "ebg-secure-boot-snakeoil" ]; then @@ -221,6 +223,30 @@
>> build:qemu-arm-test:
>>>      target:  qemu-arm
>>>      extension: test
>>>
>>> +build:qemu-amd64-test-nokernel:
>>> +  extends:
>>> +    - .build_base
>>> +  variables:
>>> +    target:  qemu-amd64
>>> +    extension: test
>>> +    no_kernel: enable
>>> +
>>> +build:qemu-arm64-test-nokernel:
>>> +  extends:
>>> +    - .build_base
>>> +  variables:
>>> +    target:  qemu-arm64
>>> +    extension: test
>>> +    no_kernel: enable
>>> +
>>> +build:qemu-arm-test-nokernel:
>>> +  extends:
>>> +    - .build_base
>>> +  variables:
>>> +    target:  qemu-arm
>>> +    extension: test
>>> +    no_kernel: enable
>>> +
>>
>> Do we always need to build and deploy those extra images?
> 
> It will not be necessary every time.
> It will need to be built when LTP is updated or when a point release is had in Debian.
> The current gitlab pipeline is not that well thought out and I think it needs to be considered.
> 

If we do not pick up the artifacts automatically from a pipeline build,
we can make these variants also manually triggered. But I still need to
understand the apparent overlap with the kernelci builds (which happen
unconditionally so far).

BTW, where is the riscv64 variant?

>>
>>>  build:x86-uefi-secure-boot:
>>>    extends:
>>>      - .build_base
>>> diff --git a/kas/opt/no_kernel.yml b/kas/opt/no_kernel.yml new file
>>> mode 100644 index 0000000..2338177
>>> --- /dev/null
>>> +++ b/kas/opt/no_kernel.yml
>>> @@ -0,0 +1,17 @@
>>> +#
>>> +# CIP Core, generic profile
>>> +#
>>> +# Copyright (c) Toshiba Corporation 2025 # # Authors:
>>> +#  Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
>>> +#
>>> +# SPDX-License-Identifier: MIT
>>> +#
>>> +
>>> +header:
>>> +  version: 14
>>> +
>>> +local_conf_header:
>>> +  kernel-version: |
>>> +    IMAGE_INSTALL:remove = "linux-image-cip linux-image-cip-rt"
>>
>> KERNEL_NAME = "", that will also disable the now pointless build of the
>> kernel.
> 
> Thank you.
> This is simpler and better.
> 
> Best regards,
>   Nobuhiro


-- 
Siemens AG, Foundational Technologies
Linux Expert Center