From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6874889650574458880 X-Received: by 2002:ac2:4827:: with SMTP id 7mr1445259lft.493.1601039806881; Fri, 25 Sep 2020 06:16:46 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:554:: with SMTP id 81ls628044lff.1.gmail; Fri, 25 Sep 2020 06:16:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoASYSRJzW2AY9WvBX8O19NwPbxbjIBnRNbPy7BpwR6hzjM7Rx0E2CDD/2d7zCvitaPS33 X-Received: by 2002:a19:a406:: with SMTP id q6mr1467834lfc.556.1601039805659; Fri, 25 Sep 2020 06:16:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601039805; cv=none; d=google.com; s=arc-20160816; b=zsjQgPl7dzRbBoD0Bl9COHBE0MnRQ93IeYxRnK8/zHGgpQ7OvwHCEySs71klfZJCJq GLUeVnZGUORH096SD2hHvqMzVk/In150VKBmst2vWr9v15U9vZ2f8XTDnIgkWwNkOgE7 YaS8LffmI1eny2hV/rL4Us8tLpO5BlegUlN5ySfWCeNu9Lso57Qem3rk1w2aZqrXdg43 Y4EXFq933c+guvC8HazTOIi6qI3PJcD5/OPFCd/xStOmBQLZtOP1U05R22ZADnbalA1+ auRZqdbcqTjoEqWnVy8kweS26JmWfmk8GXLhW5bmRjy455MY3yqeOuUUWCZXNZnK7Jtx U8pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=WhJ1y8cQG8v+Earel0Ca8f2xZkXGEReE3fU9zffvj8k=; b=xUgMHze6T+9GEecgqyO4IsPLvDKClRZV3gfL6B9SMvWlO0Zp4nrMsgr10ztZr1zM6m AAL7jEyjW3jZ64KT7t8KFHaYVDkVSsCIpdSiXNozoJtO/7m7lkmvHq6A7kRax8oeuErk aa/SWi7VraOogzU3xp4mdAwgFBPIhFlB9QVcaZHOwMdcRb2xP3ASATYab/8uvXt4LdC3 UEukNP7PvsuSVP3IXP8gj+EZw2Y/Bq5Sz5d1wQN5N7VziheHvYlmCYWQBn9aWLh7rw5N 8f4aj1Domb04Og7zVEGl3AOYYe1x/kEtOMpBxw0m21qBsb9rvttdLkEetTkZwN16fMT8 uSlA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id e1si88847ljg.6.2020.09.25.06.16.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Sep 2020 06:16:45 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 08PDGi45031907 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Sep 2020 15:16:44 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.29.103]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 08PDGh1x010832; Fri, 25 Sep 2020 15:16:43 +0200 Date: Fri, 25 Sep 2020 15:16:40 +0200 From: Henning Schild To: Harald Seiler Cc: isar-users@googlegroups.com Subject: Re: [PATCH v2 1/3] classes: Add initramfs class Message-ID: <20200925151640.0666f4bb@md1za8fc.ad001.siemens.net> In-Reply-To: <20200923162046.206888-1-hws@denx.de> References: <20200921104212.1387227-1-hws@denx.de> <20200923162046.206888-1-hws@denx.de> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: J9NEYnWRHzYj To me this sounds like a "buildchroot" specifically for the initramfs. And the target would be to keep the stuff we need only in the initramfs out of the "final" rootfs. More inline. On Wed, 23 Sep 2020 18:20:44 +0200 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). I was about to ask why not just use that chroot ... got it. > This also means, with this new approach, the integrator has > maximum control over the contents of the initramfs. And maximum responsibilty. Using an initrd that was not generated from the "final" rootfs probably violates some assumptions or can at least be seen as highly unusual. Not sure that is or could become a problem. > - 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. Yes dead-weight, but is it heavy? In terms of disk-space we are probably talking about really not much, if you compare to what applications will pull in. But i do not know. I guess lvm, mdadm, cryptsetup and friends could really add up ... but wic does not have that anyways ;) > 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. I guess one can pass that hash to the initrd with an argument from the kernel command line. So you probably pass it into your wks, or whatever imager controls the cmdline. How much does the generation of the initrd impose on the "real" rootfs, in terms of "dead" packages? And how polluted can an initrd become when generated from a rootfs that "contains too much"? Maybe you have numbers for your layer giving a perspective on the gain. Generating the initramfs not from the rootfs means that the manifest will not mention all packages shipped in the image, which could cause legal issues when overlooked. Adding the manifests might result in too much clearing effort, because not all that is in the initramfs-buildchroot will be in the initramfs. Henning > Changes in v2: > - None (just added examples in new patches) > > 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