From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6874889650574458880 X-Received: by 2002:a1c:23c9:: with SMTP id j192mr785359wmj.6.1600777138436; Tue, 22 Sep 2020 05:18:58 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:dd0a:: with SMTP id a10ls3938566wrm.2.gmail; Tue, 22 Sep 2020 05:18:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymrxKf63aEu0lHYzjoETMwug7UyL/fo7qMNzE3A/0Iwy8iZUFAmSGjS3JGljPz/u7bczNM X-Received: by 2002:adf:e312:: with SMTP id b18mr5392116wrj.372.1600777137535; Tue, 22 Sep 2020 05:18:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600777137; cv=none; d=google.com; s=arc-20160816; b=UxKqN+rMc4dHsO/WrbvN7qS7DgwB3zwHuF2KoDgU9o4G4mDwekVAAhcGp5HDBIIkKK LoR3sZgSdD+AevpuNSerwQ5e0fsVoBkGH0teShJ/YGLlo3ppgkx+TI6DefTAH682/ZmM vGLTHXfM7Vq+hFOzAWVCYsrauSfOihEikeXTemG8d8ASxdEamvNP2/MbaMdyjnSgb7g5 eQmqXA1d/hRPTItIiOxXtYPkVMUzjERmywZYy3L2OADeSkP6w5VBTswpShlNKge7OwKn rKrzjji7wmrGbP8BGv2anMuxzROpZ8agnePTwgSN/WrTf3t3rRpQtWQbhzknwsXgFqDJ HkDw== 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:to:from:subject:message-id; bh=09tpujDaV1J/j5yVVjnOrrax1Ga6aYtK/zYtGAP/Azc=; b=Vn8DYLdK+H3Cfk8Hc+Zl18sjxsssZEKyEel2i43PTICu8/2TlGk1qI9S4QKzpIMxnn EeHcCcsPu/RE0RKJlUtL9EzxcQ+YOwycTZb9weBc105MdFRzdgVFM5t3gpuoQ5OUTyl4 PRXi4UvggQYZUxaTLCfzj8fjbz++pd1C7Jt4WU29nW+7xrsGKTum7OEeb5oAEDbZjhQr 2dzZ3RylpOVEnT0CvsKoPLwZ5A6sInNq97VIJJN9ZQH4SDeaBndNKjavSHJw6nGFm575 4MuHPnhx46WObsU5BSnd07S1SdeoYX5tvmeOblb8angkOqWHHb5HTgHgFnAE4GFV1pCk Z93A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 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.9]) by gmr-mx.google.com with ESMTPS id 21si74412wmj.2.2020.09.22.05.18.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 05:18:57 -0700 (PDT) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of hws@denx.de) client-ip=212.18.0.9; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 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 4BwgMj2H0rz1qs0j; Tue, 22 Sep 2020 14:18:57 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4BwgMj1x6jz1qvhX; Tue, 22 Sep 2020 14:18:57 +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 kcvfzQ5SOwTj; Tue, 22 Sep 2020 14:18:55 +0200 (CEST) X-Auth-Info: mP8123wgWd/9gIIek147g50W7eZbK0MFGfib3dJ1gRQ= 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, 22 Sep 2020 14:18:55 +0200 (CEST) Message-ID: Subject: Re: [RFC PATCH] classes: Add initramfs class From: Harald Seiler To: Gylstorff Quirin , Jan Kiszka , isar-users@googlegroups.com Date: Tue, 22 Sep 2020 14:18:55 +0200 In-Reply-To: <64096ac1-3326-b1eb-ec37-0e6f05f68a2a@siemens.com> References: <20200921104212.1387227-1-hws@denx.de> <433a8c30-796e-344f-35b7-0ce17a1fad7f@siemens.com> <64096ac1-3326-b1eb-ec37-0e6f05f68a2a@siemens.com> 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: dtpUneSfHp6z Hi, On Tue, 2020-09-22 at 14:10 +0200, Gylstorff Quirin wrote: > > 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? You'll need to add the package for the custom module to INITRAMFS_INSTALL or INITRAMFS_PREINSTALL as well of course. If you do that, I don't see a reason why it shouldn't work (that would be a bug) but I did not test this so far. -- Harald 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