From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6874889650574458880 X-Received: by 2002:ac2:4c9c:: with SMTP id d28mr1576110lfl.93.1600772693628; Tue, 22 Sep 2020 04:04:53 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:554:: with SMTP id 81ls238484lff.1.gmail; Tue, 22 Sep 2020 04:04:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAJEEqQPJmVqEnCsNqL0HLFkxwTPRww/jthOC8OttmAhNeAGmboowT8tAIHZ6YtrvZEe4J X-Received: by 2002:a19:4bc8:: with SMTP id y191mr1611605lfa.491.1600772692383; Tue, 22 Sep 2020 04:04:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600772692; cv=none; d=google.com; s=arc-20160816; b=EX5avyd7tWd/TNrTsNn8RsE9JOvXoki64jer2/9DU8blOSi8e1Bn5akCzrbEmZToFf B+EQEJKtbYv9drZf4nyNxV6YIrZ4yDtYb0UymoXuCYwAuqLzuEGqQvOqYP9wF7dT5Lib 2VWcJvy9wdBlratKGufaIKU8HoSHtnMUDkLdQANEg6A6I+ZeLv12GSvX2wxr1Pdn2/2w sCgxl2RQq1Qo6FV1RuEaFpH808jygoc55gKKuFmdHkIJbGECbTQGp4ateP+BDajJ7zBy r5fc1zmDwhj0jFFWbYIdparxMeG2DwDiYVpH1VQoi86xQBWt0LM/RuwrBXl0O6f1YsxB FCWA== 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:cc:to:subject; bh=+l0Qa1h2Wyze1QDTsfE3xBALHf5ivyC4Qhe4xiDvStU=; b=oouZaVy6a6OrMTHdIQYgAFvdWU4GWXlcGgpvddfX2/RJ9K7jT3O02RMyhHY9nzhNZu vm8/u7mfz+wj+uA4ropYEex57mwFSitHFnpYCMpN3rJHtGdy/lkZkqdNgVw0QW3GUVpo zxjaazDY//nB+SE1i7Nrx+bug5M4NfZgN8AXobk1Y/tqloI3/hsfqqvwiXznv+qmAaUd xGeLsv+Kpho0sZ4de8f/LRKKN+HgHfciuG0nEDWpciFYdyD8QpqxACf7iegkVJwiy89N eUTVFIPdKFrq0xNVxcz6TkGW8ykh7yeVwNiUYOwXEkGql12IWEjU7r9hm3PPCjyjvCcy YYhw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 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 david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id f12si507417lfs.1.2020.09.22.04.04.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 04:04:52 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 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 david.siemens.de (8.15.2/8.15.2) with ESMTPS id 08MB4pnU008844 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Sep 2020 13:04:51 +0200 Received: from [139.22.130.132] ([139.22.130.132]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 08MB4mpJ007685; Tue, 22 Sep 2020 13:04:49 +0200 Subject: Re: [RFC PATCH] classes: Add initramfs class To: Harald Seiler , isar-users@googlegroups.com Cc: Quirin Gylstorff References: <20200921104212.1387227-1-hws@denx.de> <433a8c30-796e-344f-35b7-0ce17a1fad7f@siemens.com> From: Jan Kiszka Message-ID: <18dbad5d-7272-d4c2-8e4a-fef107ace0bd@siemens.com> Date: Tue, 22 Sep 2020 13:04:49 +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; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: NaFVMOuzUsMW On 22.09.20 12:34, Harald Seiler wrote: > On Mon, 2020-09-21 at 21:25 +0200, Jan Kiszka wrote: >> On 21.09.20 12:42, Harald Seiler wrote: >>> Add a new "image" class for generating a custom initramfs. It works >>> like this: A new minimal debian rootfs is bootstrapped and all >>> dependency packages for the new initramfs are installed. Then, an >>> initramfs is generated from this rootfs and deployed like usual. >>> >>> This new initramfs.bbclass "image" class should be pulled in by an >>> "initramfs image" recipe. Said recipe then specifies all dependencies >>> of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which >>> are analogous to the respective IMAGE_* variables). >>> >>> initramfs.bbclass intentionally does _not_ expose a mechanism to change >>> /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules. >>> Changes to their settings are better done via packages that deploy >>> conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module >>> fragment files to /usr/share/initramfs-tools/modules.d/. >>> >>> Signed-off-by: Harald Seiler >>> --- >>> >>> Notes: >>> I had this idea while searching for a way to build an initramfs that >>> uses dm-verity to assert integrity of the rootfs. To me, this feels >>> like a much cleaner solution than anything else I tried and I'm happy to >>> report that, using this approach, I got everything working nicely in the >>> original project. >>> >>> In my opinion, this design has a number of advantages over the previous >>> solutions we have seen so far: >>> >>> - It does not suffer any kind of initramfs pollution, caused by >>> packages installed into a rootfs. This is a big problem when trying >>> to generated an initramfs from e.g. `buildchroot-target` as many >>> unrelated packaged could be installed there which would all get >>> pulled into the initrd (if they install hooks/scripts). >>> >>> This also means, with this new approach, the integrator has maximum >>> control over the contents of the initramfs. >>> >>> - There are no needs to change the initramfs generation process in any >>> way, the debian tooling can be used exactly like its meant to. >>> >>> - As most isar-generated images will never regenerate the initramfs >>> from the running system, all initramfs related packages are dead-weight >>> to the image. This is a problem when trying to generate the initramfs >>> from the actual image rootfs. >>> >>> When it is necessary to rebuild the initramfs in a running system, >>> the packages designed for this new class could just be installed into >>> the rootfs, without any changes necessary. This means, any generic >>> initramfs module packages can be used both with the in-rootfs mechanism >>> and initramfs.bbclass. >>> >>> - Because of this complete isolation and independence, implementation >>> of complex logic is much easier: For example dm-verity needs >>> a root-hash that is only available after the rootfs has been cast into >>> a filesystem image. With this new approach, this can be modelled with >>> a simple task dependency. >>> >>> meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++ >>> 1 file changed, 41 insertions(+) >>> create mode 100644 meta/classes/initramfs.bbclass >>> >>> diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass >>> new file mode 100644 >>> index 000000000000..8af9b4b379a5 >>> --- /dev/null >>> +++ b/meta/classes/initramfs.bbclass >>> @@ -0,0 +1,41 @@ >>> +# This software is a part of ISAR. >>> + >>> +# Make workdir and stamps machine-specific without changing common PN target >>> +WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}" >>> +STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}" >>> +STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*" >>> + >>> +INITRAMFS_INSTALL ?= "" >>> +INITRAMFS_PREINSTALL ?= "" >>> +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs" >>> +INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img" >>> + >>> +# Install proper kernel >>> +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}" >>> + >>> +# Name of the initramfs including distro&machine names >>> +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}" >>> + >>> +DEPENDS += "${INITRAMFS_INSTALL}" >>> + >>> +ROOTFSDIR = "${INITRAMFS_ROOTFS}" >>> +ROOTFS_FEATURES = "" >>> +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}" >>> + >>> +inherit rootfs >>> + >>> +do_generate_initramfs() { >>> + rootfs_do_mounts >>> + rootfs_do_qemu >>> + >>> + sudo -E chroot "${INITRAMFS_ROOTFS}" \ >>> + update-initramfs -u -v >>> + >>> + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then >>> + die "No initramfs was found after generation!" >>> + fi >>> + >>> + rm -rf "${INITRAMFS_IMAGE_FILE}" >>> + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}" >>> +} >>> +addtask generate_initramfs after do_rootfs before do_build >>> >> >> I think the public would also benefit from a use / test case, i.e. some >> recipe that inherits this and generates an own initramfs with >> extensions. For merging this, that will be mandatory anyway. > > Makes sense. What do you think would be a good and upstream-viable > example for this? I can't think of anything trivial _and_ generic that > would still be a sensible use-case - the whole reason for this bbclass is > cases where the a custom initramfs is needed, after all ... > > One idea would be to get the remaining dm-verity recipes upstream as well. > This would definitely be quite a bit of work as the ones I have right now > are not entirely generic yet ... Though you mentioned that you're > interested in making them available at some point anyway, so maybe this is > the way to go? > > Otherwise (or in addition), I could add a dummy recipe that e.g. just > prints something during boot to meta-isar, to show how it works ... > That would have been exactly my suggestion as well. Can still be replaced later on when we upstream things like dm-verity generation. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux