From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6874889650574458880 X-Received: by 2002:a7b:c14f:: with SMTP id z15mr322871wmi.73.1602601883756; Tue, 13 Oct 2020 08:11:23 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:7d02:: with SMTP id y2ls68394wmc.2.canary-gmail; Tue, 13 Oct 2020 08:11:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx4N8y2Tz6rD45KWpaQkcISrKRkCS6w8/0uHfW4dP5EnlGshBrTCOTPFiUTZW/N/GR0jEtI X-Received: by 2002:a1c:6788:: with SMTP id b130mr319482wmc.91.1602601881955; Tue, 13 Oct 2020 08:11:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602601881; cv=none; d=google.com; s=arc-20160816; b=Wc/XdtG9ZIAt9pEtOFS0VBtFJRtmYTxSyM3XnhBWYFNbXRTuHmDhwnGUSfDOLL/RAY VWe3My2XnTEPjGAHbOYXicETgeQgzyr4l8QmvZx9xLQ9ENa1WFyVow1HPuLGb9furnrS iwsSgjWJ4Gz72TR+KP89vShisDa5wJC26Quxxlg7frfiO5FxOGfbndnCtZRp6dHKmXH6 In0voh95E8DMCu741+dUZw5kzetMvXEsfQsxkMWpsTOsOK51hdYR2NabylvpEPhxTGou kxu9RU6fs5gZO3EWVHYK5MvnSPMv3nni0JDvfKOnisIQ4hppjis2+YeQKPpgQLMrK3mv 8GFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=/rDdPuqzYJxVvjkSXuTKFENylVFBamGneSCZ0gga92g=; b=Tixuvwaycb7nTXtKc7KnnwV+JR0Z6kgZq/5Fq7b7AGD0abz15bWdc/rdbVj2M+G4uu Xt+bRQaflCvNvlO1iLlY0aB0cQv/jBmiT6dcrHDiEVK+C0iKSTD5onp7f1+p3VLYSbqD qze+0/absAqIIjjaKN+E6IZ+h4Uutkbf2twmxZjxrHMG1UgPSAth2zAJQUdo8XCeqKpI R8tZPh4viJWVSvXXVGHKK7H1u78g9BFJ+2erjifpn1Lc/EAGtUuudSN0fX37kSobJ8kn tm1xkxHsqzUFUHWVFGusXK8IoTdAiEja73SVjY/4RKTGO4GhkVikw33AkqBA58xQb0lc DKfQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id v12si2469wmh.0.2020.10.13.08.11.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 08:11:21 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 09DFBLh4013518 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 17:11:21 +0200 Received: from [139.25.68.37] ([139.25.68.37]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 09DFBKaj024666; Tue, 13 Oct 2020 17:11:20 +0200 Subject: Re: [PATCH v2 3/3] Add custom isar-initramfs example To: Harald Seiler , isar-users@googlegroups.com References: <20200921104212.1387227-1-hws@denx.de> <20200923162046.206888-3-hws@denx.de> From: Jan Kiszka Message-ID: Date: Tue, 13 Oct 2020 17:11:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: FmbJFIgufWgU On 25.09.20 13:28, Harald Seiler wrote: > On Fri, 2020-09-25 at 11:13 +0200, Jan Kiszka wrote: >> On 23.09.20 18:20, Harald Seiler wrote: >>> isar-initramfs is a custom initramfs which additionally has the >>> initramfs-example module installed. >>> >>> Signed-off-by: Harald Seiler >>> --- >>> >>> Notes: >>> Maybe this initramfs should be tested in CI somewhere? I'm unsure what >>> makes sense, and how to "force" this custom initramfs into a CI target. >>> >>> .../recipes-initramfs/images/isar-initramfs.bb | 18 ++++++++++++++++++ >>> 1 file changed, 18 insertions(+) >>> create mode 100644 meta-isar/recipes-initramfs/images/isar-initramfs.bb >>> >>> diff --git a/meta-isar/recipes-initramfs/images/isar-initramfs.bb b/meta-isar/recipes-initramfs/images/isar-initramfs.bb >>> new file mode 100644 >>> index 000000000000..aaa0350aab20 >>> --- /dev/null >>> +++ b/meta-isar/recipes-initramfs/images/isar-initramfs.bb >>> @@ -0,0 +1,18 @@ >>> +# Example of a custom initramfs image recipe. The image will be deployed to >>> +# >>> +# build/tmp/deploy/images/${MACHINE}/isar-initramfs-${DISTRO}-${MACHINE}.initrd.img >>> +# >>> +# This software is a part of ISAR. >>> + >>> +inherit initramfs >>> + >>> +# Debian packages that should be installed into the system for building the >>> +# initramfs. E.g. the cryptsetup package which contains initramfs scripts for >>> +# decrypting a root filesystem. >>> +INITRAMFS_PREINSTALL += " \ >>> + " >>> + >>> +# Recipes that should be installed into the initramfs build rootfs. >>> +INITRAMFS_INSTALL += " \ >>> + initramfs-example \ >>> + " >>> >> >> If this recipe is not pulled somewhere, it's dead. > > Right, that's why I was asking where to put it. > >> Some test-only dependencies we had to local.conf in scripts/ci_build.sh. >> Or you add it to meta-isar/conf/local.conf.sample. >> >> If added, will it simply replace the default initramfs? Or is more needed? > > Well, there really isn't such a thing as the default initramfs right now. > `image.bbclass` deploys its own initramfs (the one debian installed to > /boot) to `${IMAGE_FULLNAME}-initrd.img` which further tasks could then > reference when building e.g. a fitImage or it could be added to > IMAGE_BOOT_FILES for WIC. > > Similarly, the new `initramfs.bbclass` deploys the final artifact to > `${INITRAMFS_FULLNAME}.initrd.img`. What happens after that is entirely > up to the integrator. After all, this image-class is meant for cases > where customization beyond the abilities of the current in-rootfs > initramfs are needed. As an example, a fitImage recipe could use this > like > > INITRAMFS_RECIPE = "isar-initramfs" > > INITRD_IMG = "${PP_DEPLOY}/${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img" > do_fit_image[depends] += "${INITRAMFS_RECIPE}:do_build" > > --- > > Now, for CI if we want to include this custom initramfs, we'd need to > either modify some image recipe to pull it in as shown above or build it > separately and then start qemu with > > -initrd build/tmp/deploy/images/qemuamd64/isar-initramfs-debian-buster-qemuamd64.initrd.img > > somewhere. But I'm not sure if that's easily integrated into the current > setup? > > IMO the next best thing would be to just build test it. Would adding > > mc:qemuamd64-buster:isar-initramfs > > to TARGETS_SET in ci_build.sh work? > We already have fit/ubi example. Could that be expanded better to stress this? Otherwise, I'm find with your suggestion above. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux