From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6874889650574458880 X-Received: by 2002:ac2:4c31:: with SMTP id u17mr391277lfq.1.1601987057003; Tue, 06 Oct 2020 05:24:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:a556:: with SMTP id e22ls1660318ljn.9.gmail; Tue, 06 Oct 2020 05:24:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKQYcszKLfGag7Sp9mpJGuGdGqe7WNocWtzlCLD/N84Il7RNpVYr0JyFDn0kHJZFObZ1GF X-Received: by 2002:a2e:a54a:: with SMTP id e10mr1552175ljn.87.1601987055700; Tue, 06 Oct 2020 05:24:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601987055; cv=none; d=google.com; s=arc-20160816; b=Rfvky50Aw6Y4lXafT8bz9dey95cerBaVxpTKjCvmcq8f8tQ7Jho/FtZDxN224TsE32 AqOaD06qLqZOyY/xpNxF4W+wB28VBjr7afI9ZunDeepPn/ihoLtXeKZdxweAwTbF3Dfe G6fXlfPDEYFu7DLHa819Xw3PNAMPBIPxZ5QP2LiX+P+KeTG6RD8IdnMCiwh3pCQ1Qdv+ 0LMebT2QOgJ/7GODYmj7f2WoaPpR1aB4TmaUGUVoXt7JbtNNCrQoCQr9DQXQ0nkx8LbF zGddRe/Kp/CzMP1d5GntTo9pDWskaO+UFNgPfoCFzYm9ZMXOWOuDPNSE7rOeGSiXYJGj jhTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id; bh=a2vTYmTWFt0NTb7FNjLuyG8nM2l3H8lAXFvwd/LsZ/w=; b=fhNogHpHzRXsCho1qNgStFIdF3mKwgzNiEV/auUlhSnRZF5kxhxcm5TCrYX7CPi7a+ //pqkw9vV83s9b46UDQTwUsIQUcaS6BY3sUHe8saD/GMKtkCsPszBtQJcCm5f9ie4nRw gbBpbA0QZTKDpw1Miwqfu5gjTJnzeYoKmBs6n0aHKCpqzdfrgHv7xWspEEFla/o6ZR69 x6Ecm8lK/4ukegstcgD0Pn4Z8a+71MNwC5PrtMd96uVocRCHRiuGUswkJ5H6UbBvEawB 8HaTecVRS6pPTcB3t5XzkiVbaQsxuZvesnKblIIlas2DS9KhJRQbN8rkmPs6LAv0HsTP ah2g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of hws@denx.de) smtp.mailfrom=hws@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.10]) by gmr-mx.google.com with ESMTPS id d1si98592lfa.11.2020.10.06.05.24.15 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 05:24:15 -0700 (PDT) Received-SPF: neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of hws@denx.de) client-ip=212.18.0.10; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of hws@denx.de) smtp.mailfrom=hws@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4C5GqM0m5bz1sNcw; Tue, 6 Oct 2020 14:24:15 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4C5GqM0Y2Yz1qv2q; Tue, 6 Oct 2020 14:24:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 6GoYUR5G8hXg; Tue, 6 Oct 2020 14:24:13 +0200 (CEST) X-Auth-Info: /VOfBbNqMuVOsl+gfe9e1rFvkLhp+ZoWhwZDAWUBqns= Received: from maia (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Tue, 6 Oct 2020 14:24:13 +0200 (CEST) Message-ID: <8f7d6b918fa44a492940540f8bce8f43a3a2592d.camel@denx.de> Subject: Re: [PATCH v2 1/3] classes: Add initramfs class From: Harald Seiler To: Henning Schild Cc: isar-users@googlegroups.com Date: Tue, 06 Oct 2020 14:24:13 +0200 In-Reply-To: <20200925151640.0666f4bb@md1za8fc.ad001.siemens.net> References: <20200921104212.1387227-1-hws@denx.de> <20200923162046.206888-1-hws@denx.de> <20200925151640.0666f4bb@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUID: atIMmDvvQ3YB Hi, On Fri, 2020-09-25 at 15:16 +0200, Henning Schild wrote: > To me this sounds like a "buildchroot" specifically for the initramfs. That's pretty much what it is. With the difference to the other buildchroots that it is not shared when building multiple initramfs images so each one has its own rootfs. > And the target would be to keep the stuff we need only in the initramfs > out of the "final" rootfs. This is a nice side-effect but not the main reason I propose this. Just to make it clear: I do _not_ want this to be a replacement for the current way of building the initramfs from the image rootfs. This new bbclass is meant for situations where in-image generation falls short or is otherwise inappropriate. A few examples: - As already mentioned, it makes dm-verity setups _much_ easier and a lot cleaner because it avoids the dependency cycle that other approaches have. - This could be used to generate a completely custom initramfs-based rescue system. > 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. The vanilla initramfs from debian does not suffer any problems, as long as you make sure the correct kernel modules are included. This should usually just work(tm) because initramfs.bbclass does the exact same thing as image.bbclass: > > +# Install proper kernel > > +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", With upstream initramfs modules, care has to be taken, of course. Let's look at cryptroot from cryptsetup as an example: This module needs a correct /etc/crypttab in the initramfs-chroot to properly unlock the root filesystem. For any other partitions, crypttab needs to be in the actual image rootfs. You could now either have two separate crypttabs, one with just the rootfs in initramfs-chroot and one for the rest in the actual image. Or, what I'd find the cleaner solution: A config-package containing /etc/crypttab that is deployed to both the image and the initramfs-chroot. That said, I do not see why one would want the custom initramfs for this scenario ... The in-image version will work just fine. > > - 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 ;) I don't think it would amount to much. If you're really short on space, it could matter (as you said, one could pull any dm tooling out of the rootfs), but apart from that I don't think it is that relevant. > > 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. I don't see this working without creating a dependency cycle somewhere ... I did try to explore alternative solutions but it all ended up requiring ugly hacks at some point or another. > 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. The main motivation for me was a clean dm-verity setup so I do not have numbers on this aspect. I don't expect it to be much though. > 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. Well you won't install anything into the initramfs-chroot that won't in some form or another leave a trace in the initramfs so I'd say merging the manifests does make sense here. -- Harald > 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 -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de