From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6874889650574458880 X-Received: by 2002:a1c:f008:: with SMTP id a8mr684019wmb.155.1600776621766; Tue, 22 Sep 2020 05:10:21 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:a58a:: with SMTP id o132ls1401117wme.3.gmail; Tue, 22 Sep 2020 05:10:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3q42Vj/QyFOMC7MGt+Fpk61bxOXB9/KefxEiP5GoDUB0B4NU9O7f8XBGPY1oEfLthtI2V X-Received: by 2002:a7b:c241:: with SMTP id b1mr700686wmj.98.1600776620806; Tue, 22 Sep 2020 05:10:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600776620; cv=none; d=google.com; s=arc-20160816; b=VoNQQqQGDfMiQSrvA+aVqZd7CrfpnEboijx95XLiQU35cAlnh3FmAQR5/KOQBrTqz0 JCjuuorG/kj2W6V5hP92xp6kNTYaEmyED7rUls3EA2InINnzDNTvHQcTQm3IxDU31tjt mq6Fb9OsVsEyJcG5BuiXySicbiiatJMDSuteKvvpFP+1sxzOSzi636iS8Xxsoy68Mqo2 hRLVNGdXXkZ0MuGpkk4Qn2UCT8+GQrOFz8UaLDaj8JErcuaIMKg2icfZymqt31W8Zn9E XgFjlzj1jyYYT0u3N1sGpIW9exqK/RGO5R1el8TxcXWD8NqO/ro0MgBRWxtcIpXLGoOY 2JEg== 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=qP6ZbQqes6f6HxBYh3RqXH1lj7mZGR3iPihHAbMuz9I=; b=vlIgC+cuX2WdPqVtFrIRm/nxXfmFBboKiK8bcEsN1dNaG3HGmcjRB7swN8bjCvoHOp T9BLA5zKqKmKJtTZ3hmQhGcc1u/ReUbQ+G0W2kb/IT9iazAgnD3f6jm+zg8J9vlM1jQw UH//INHWTWC5jMDQd6Ebcv2WrZctUQKC3e4GbMAu4wyVJ3N8oDy+ELGPbSc9pMeLPhKt 0sBebfhf10NishxaCIN8G66LmvhQUSiq4+5EPbVPySnlvkiZypkutgUjXwmUOCOQqgmt 6MArH1o+GpE+QAsCQFf9+eQ7nk2wDtLXs7wbBGFc/Hg/n/nb9AU/bDtNfq2jVgENtGQs /z8Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of quirin.gylstorff@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=quirin.gylstorff@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 h2si95818wml.4.2020.09.22.05.10.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 05:10:20 -0700 (PDT) Received-SPF: pass (google.com: domain of quirin.gylstorff@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 quirin.gylstorff@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=quirin.gylstorff@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 08MCAJFu022723 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Sep 2020 14:10:19 +0200 Received: from [167.87.47.88] ([167.87.47.88]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 08MCAJxj021795; Tue, 22 Sep 2020 14:10:19 +0200 Subject: Re: [RFC PATCH] classes: Add initramfs class To: Jan Kiszka , Harald Seiler , isar-users@googlegroups.com References: <20200921104212.1387227-1-hws@denx.de> <433a8c30-796e-344f-35b7-0ce17a1fad7f@siemens.com> From: Gylstorff Quirin Message-ID: <64096ac1-3326-b1eb-ec37-0e6f05f68a2a@siemens.com> Date: Tue, 22 Sep 2020 14:10:19 +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: <433a8c30-796e-344f-35b7-0ce17a1fad7f@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: /Vxn0dz482Nk On 9/21/20 9:25 PM, 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. > > Quirin, what is your impression of this approach? > > Jan > From the first look of it, looks good to me. Did you test what happens if you try to install a custom kernel module? -- Quirin