| Message ID | 20261106173235.4155305-1-bruce.ashfield@gmail.com |
|---|---|
| Headers | show |
| Series | enhance kernel -devsrc output options | expand |
On Fri, 2026-11-06 at 12:32 -0500, bruce.ashfield@gmail.com wrote: > 7-8: two general oe-core fixes, for issues I noticed in the debug > rootfs while working on this support. They aren't kernel > specific and don't depend on the rest of the series: > postinsts of debug only packages being registered against the > image, and IMAGE_INSTALL_DEBUGFS packages with broken > dependencies being silently skipped. Do you have an example of something which has a postinst which this pulls in? I'm wondering why debug src packages have postinsts :/ Cheers, Richard
From: Bruce Ashfield <bruce.ashfield@gmail.com> On Fri, 2026-11-06 at 14:08 -0500, Richard Purdie wrote: > On Fri, 2026-11-06 at 12:32 -0500, bruce.ashfield@gmail.com wrote: > > 7-8: two general oe-core fixes, for issues I noticed in the debug > > rootfs while working on this support. They aren't kernel > > specific and don't depend on the rest of the series: > > postinsts of debug only packages being registered against the > > image, and IMAGE_INSTALL_DEBUGFS packages with broken > > dependencies being silently skipped. > > Do you have an example of something which has a postinst which this > pulls in? I'm wondering why debug src packages have postinsts :/ They don't :) Nothing in the -devsrc part of the series has a postinst, and neither do the complementary -dbg packages. I hit it while prototyping the versioned package, which originally used a postinst for the /usr/src symlink (dropped, the link is now a plain file owned by kernel-devsrc). I then reproduced it with a test recipe using pkg_postinst_ontarget. I could dig up that reproducer and send it along. I should have mentioned that in the series send. The general case is that IMAGE_INSTALL_DEBUGFS takes any package. If one that is only in the debug rootfs has a postinst that defers to first boot, it gets registered in the intercepts the image shares, and do_rootfs fails trying to save a postinst for a package that isn't in the image. In oe-core, gnutls-fips and openssl-ossl-module-fips are the obvious candidates, though I haven't built either into a debug rootfs. So it's not needed by this series anymore. I'm happy to split 7-8 out and send them separately, or chuck it in the bin if it isn't necessary. I'll run it locally, since I don't throw much away! Bruce > > Cheers, > > Richard
From: Bruce Ashfield <bruce.ashfield@gmail.com> Hi all, This RFC follows on from the "Fix kernel complementary package installation" thread with Adrian, and covers the use cases listed there: debugging a kernel built for a specific MACHINE, from a debug rootfs on the host (TRACE32 and similar), or on the target. kernel-devsrc today is what is needed to build out of tree modules on the target ('make scripts prepare'): headers, Kconfig/Makefiles and scripts. It has almost no .c files, and installing it pulls in the build tools (bc, bison, flex, gcc-plugins, openssl-dev, ...), which aren't wanted in a rootfs-dbg. Adding another source package just means more maintenance and complexity. We can keep the tightly curated kernel-devsrc as the deafult, and add to it via packageconfigs. kernel-devsrc stays one package and one tree at /usr/src/kernel, where the debug info points, and PACKAGECONFIG chooses what goes in it: build: what kernel-devsrc is today, with its RDEPENDS. The default, so nothing changes for existing users. source: a curated spine (core directories plus the machine's arch), and the rest of the files the kernel build read, from a manifest of kbuild's .cmd files that kernel.bbclass now stages. No RDEPENDS. full: the whole tree. tarball: the whole tree as a tarball, to unpack elsewhere. They can be combined: "source build" gives both the source and what is needed to build modules on target. With 'build' and the whole tree, the tools to build the kernel itself are added to the RDEPENDS. The package can optionally be versioned (kernel-devsrc-<release>, with kernel-devsrc holding just the /usr/src/kernel link), so the source of more than one kernel can be installed side by side. The patches: 1: maps the kernel's build directory to KERNEL_SRC_PATH, so all of the kernel's debug source paths are under /usr/src/kernel. 2: stages the manifest of the source files the build read. 3-6: the kernel-devsrc levels, versioning, and a check that at least one level is set. 7-8: two general oe-core fixes, for issues I noticed in the debug rootfs while working on this support. They aren't kernel specific and don't depend on the rest of the series: postinsts of debug only packages being registered against the image, and IMAGE_INSTALL_DEBUGFS packages with broken dependencies being silently skipped. With: PACKAGECONFIG:pn-kernel-devsrc = "source" IMAGE_INSTALL_DEBUGFS = "kernel-dbg kernel-vmlinux kernel-devsrc" on qemux86-64 (7.2.13), rootfs-dbg gets the symbols and 254MB of source at /usr/src/kernel, and no build tools. All 9016 source files named in the kernel's debug info are there. The only ones missing are the 592 generated files from the build directory. The full tree is 1.5GB. One thing to know: if the image itself already installs kernel-devsrc, IMAGE_INSTALL_DEBUGFS won't put it in rootfs-dbg. rootfs-dbg starts from the image's package database, so it is seen as already installed, and only the debug files are copied over. That's how the debug rootfs works in general, but it will need documenting. Tested on qemux86-64 (7.2.13), core-image-minimal: build (default): same content and RDEPENDS as before. source build: the build content plus the source. build full: the image builds, and on target both 'make scripts prepare' and a full kernel build work from /usr/src/kernel. build tarball: the tarball unpacks on target, 94915 files. source: in rootfs-dbg via IMAGE_INSTALL_DEBUGFS, as above, with no build tools in either rootfs. versioned: kernel-devsrc-<release> holds the tree, and kernel-devsrc only the /usr/src/kernel link. no level set: the recipe is skipped with an error. kernel-devsrc package sizes, same build (installed size, and the rpm): level files installed rpm RDEPENDS build (default) 13623 79 MB 20 MB module build tools source 17590 254 MB 61 MB none source build 24022 283 MB 69 MB module build tools full 94915 1618 MB 251 MB none build full 94935 1630 MB 253 MB + kernel build tools build tarball 13623 278 MB 217 MB + kernel build tools, + tarball (199 MB) bzip2 versioned source 17590 254 MB 61 MB none (kernel-devsrc itself is just the 43 byte link) 'build' has the same files and size (79302094 bytes) as kernel-devsrc before the series. Bruce openembedded-core (8): kernel.bbclass: map the kernel build directory to KERNEL_SRC_PATH kernel.bbclass: stage a manifest of the source files the build read kernel-devsrc: add build and source PACKAGECONFIG levels kernel-devsrc: add full and tarball PACKAGECONFIG levels kernel-devsrc: optionally version the package kernel-devsrc: skip the recipe if no PACKAGECONFIG level is set rootfs: don't carry debug rootfs postinst registrations into the image rootfs: fail if an IMAGE_INSTALL_DEBUGFS package can't be installed openembedded-core: meta/classes-recipe/kernel.bbclass | 47 +++++++ meta/lib/oe/rootfs.py | 19 ++- meta/recipes-kernel/linux/kernel-devsrc.bb | 195 ++++++++++++++++++++++++----- 3 files changed, 231 insertions(+), 30 deletions(-)