Re: [poky] [PATCH v3] genericarm64 core-image-initramfs-boot: remove some kernel drivers

Richard Purdie <[email protected]> Fri, 17 Apr 2026 13:06:11 +0100
Newsgroups org.yoctoproject.lists.poky
Message-ID <c39bc15ec611160c073b3c1338244d1ee6a99f5a.camel@linuxfoundation.org>
On Fri, 2026-04-17 at 12:25 +0300, Mikko Rapeli wrote:
> Hi,
>=20
> On Fri, Apr 17, 2026 at 10:10:07AM +0100, Richard Purdie wrote:
> > On Mon, 2026-04-13 at 10:27 +0300, Mikko Rapeli via lists.yoctoproject.=
org wrote:
> > > genericarm64 supports a lot of HW and thus large collection of kernel
> > > drivers are enabled and installed to images by default.
> > > Subset of the kernel drivers are needed in initramfs to mount rootfs
> > > from local mass storage devices. This increases initramfs size a lot
> > > and with new kernel config updates even more. Thus remove kernel
> > > drivers from initramfs image which are not needed for mounting
> > > rootfs from local mass storage devices. GPU, Bluetooth, NFC,
> > > sound, networking etc support is not needed in the initramfs.
> > >=20
> > > According to buildhistory core-image-initramfs-boot size is reduced
> > > from 118 to 83 Mb.
> > >=20
> > > Signed-off-by: Mikko Rapeli <[email protected]>
> > > ---
> > > =C2=A0.../images/core-image-initramfs-boot.bbappend | 28 ++++++++++++=
+++++++
> > > =C2=A01 file changed, 28 insertions(+)
> > > =C2=A0create mode 100644 meta-yocto-bsp/recipes-core/images/core-imag=
e-initramfs-boot.bbappend
> > >=20
> > > v3: added PATHS_TO_REMOVE variable so that it can be customized
> > > =C2=A0=C2=A0=C2=A0 as suggested by Jose Quaresma <quaresma.jose@gmail=
.com>
> > >=20
> > > v2: https://lists.yoctoproject.org/g/poky/message/13894
> > >=20
> > > diff --git a/meta-yocto-bsp/recipes-core/images/core-image-initramfs-=
boot.bbappend b/meta-yocto-bsp/recipes-core/images/core-image-initramfs-boo=
t.bbappend
> > > new file mode 100644
> > > index 000000000000..2298c2f94740
> > > --- /dev/null
> > > +++ b/meta-yocto-bsp/recipes-core/images/core-image-initramfs-boot.bb=
append
> > > @@ -0,0 +1,28 @@
> > > +POSTFUNCS =3D ""
> > > +POSTFUNCS:genericarm64 =3D "reduce_initrd_size"
> > > +
> > > +PATHS_TO_REMOVE =3D ""
> > > +# these kernel modules are not needed for rootfs mount from local ma=
ss storage
> > > +# and can be loaded from main rootfs by udev
> > > +PATHS_TO_REMOVE:genericarm64 =3D "\
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv=
ers/bluetooth \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv=
ers/gpu \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv=
ers/media \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv=
ers/net \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv=
ers/nfc \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv=
ers/usb/gadget \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/fs/f=
use \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/=
bluetooth \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/=
bridge \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/=
netfilter \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/=
nfc \
> > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/soun=
d \
> > > +"
> > > +
> > > +do_rootfs[postfuncs] +=3D "${POSTFUNCS}"
> > > +reduce_initrd_size () {
> > > +=C2=A0=C2=A0=C2=A0 if [ -n "${PATHS_TO_REMOVE}" ]; then
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rm -rf ${PATHS_TO_REMOVE}
> > > +=C2=A0=C2=A0=C2=A0 fi
> > > +}
> > > +
> >=20
> > This is a tough one. There are some simple things like "POSTFUNCS"
> > being a bit generic as a name. I also worry a little this may trip up
> > yocto-check-layer with the added variable POSTFUNCS, even if it is
> > empty. I think if we're creating this as API, listing the directories:
> >=20
> > =C2=A0=C2=A0=C2=A0 drivers/bluetooth \
> > =C2=A0=C2=A0=C2=A0 drivers/gpu \
> > =C2=A0=C2=A0=C2=A0 drivers/media \
> > =C2=A0=C2=A0=C2=A0 drivers/net \
> > =C2=A0=C2=A0=C2=A0 drivers/nfc \
> > =C2=A0=C2=A0=C2=A0 drivers/usb/gadget \
> > =C2=A0=C2=A0=C2=A0 fs/fuse \
> > =C2=A0=C2=A0=C2=A0 net/bluetooth \
> > =C2=A0=C2=A0=C2=A0 net/bridge \
> > =C2=A0=C2=A0=C2=A0 net/netfilter \
> > =C2=A0=C2=A0=C2=A0 net/nfc \
> > =C2=A0=C2=A0=C2=A0 sound \
> >=20
> > and then adding the prefix would probably be cleaner too. Those are all
> > easier tweaks.
> >=20
> > The bigger challenge is "generic" kernel adding all this. Ideally you
> > wouldn't install these things to the initramfs in the first place, then
> > you wouldn't need to delete them. I'm not sure how you could
> > detect/filter and install only the subset of modules you want, or how
> > that list of modules would be maintained/updated.
>=20
> kernel-modules correctly get installed to all images through MACHINE_EXTR=
A_RDEPENDS.
> This is flexible to drivers being built-in or modules. IMO initramfs
> image should not be explicitly tied to the exact kernel config and thus
> should not depend on the exact set of kernel module packages. A slightly =
more abstract
> interface between kernel and initramfs image is needed, and "kernel-modul=
es"
> decent at that. This works well for the real rootfs but is not optimal fo=
r
> initramfs.
>=20
> > A different package to "kernel-modules" could be one idea, how you
> > construct that, again, I'm less sure. The above filter list could be
> > used to iterate the modules and filter by path I guess?
>=20
> I had a patchset for this but ran into issues with it.
>=20
> https://lists.openembedded.org/g/openembedded-core/topic/112087526#msg214=
354
>=20
> I don't see how that can move forward though.

The problems there didn't seem unsolvable but I don't remember the full
details. I think we should revisit that in 6.1.

> > Now we've merged the firmware update, the builds are breaking but some
> > of these kinds of changes are probably too late for the release/LTS.
> >=20
> > Perhaps we just have to increase the size of the initramfs for now :(
>=20
> Sigh, alright then.

We're too close to release to start doing other things unfortunately.

Cheers,

Richard