Re: [RFC PATCH] classes: Add initramfs class

[Harald Seiler <hws@denx.de>]

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 <hws@denx.de>
> > > ---
> > > 
> > > 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