Re: Remove kernel image and modules from rootfs
On 1/3/23 16:58, Konstantin Kletschke wrote:
On Mon, Jan 02, 2023 at 05:11:35PM +0100, Quentin Schulz wrote:So, you needed the extra :beaglebone-yocto because the machine configuration file is parsed after local.conf, therefore since beaglebone-yocto.conf file has:Thank you :-)but this is now deprecated for kirkstone and should be done this way:This makes sense, I'll send a patch updating the documentation to reflect
MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
your local.conf changes would be overridden while parsing the machine configuration file.
By using the OVERRIDE mechanism, we kinda cheat this by making the variables in local.conf "more important" than the machine conf file's.
You don't need the :beaglebone-yocto OVERRIDE for the :remove but it's "better" this way so that if you build multiple machines with the same local.conf, you don't impact other machines as well.
Would highly recommend not doing that though, having two configruation files with the same filename is not nice to your users, because then the order of inclusion of the layers will decide which file gets picked.I suggest you create your own machine configuration file which requiresMeanwhile I did something similair, I cloned the machine
Create your own my-beaglebone and in there have:
MACHINEOVERRIDES =. "beaglebone-yocto:"
The first line will allow recipes to use the :beaglebone-yocto OVERRIDE to match both the original beaglebone-yocto and your my-beaglebone machines.
Thanks for your enormous useful hint to the modification needed forBe careful, :remove are final, you cannot re-add its content later on. SO if you expect users to reuse and extend your image recipe while having :remove in there, you'll have unhappy users :)
in the image config, which might be even more useful for my approach toIt can be modified in any configuration file I believe, though local.conf is the only one that makes sense to me, anything else is bad practice.
However, you can pass MACHINE=my-beaglebone to bitbake, e.g.:
MACHINE=my-beaglebone bitbake my-image
would build my-image for this machine specifically.
If I go with the additional machine approach I am searching for a way toWhat exactly should be different between your images per machines? If we're talking about some specific BSP components differing (e.g. kernel, bootloader, tf-a, op-tee, etc... basically anything NOT userspace), it's better IMHO to specify those machine specific packages as MACHINE_EXTRA_RRECOMMENDS or MACHINE_ESSENTIAL_EXTRA_RDEPENDS in your machine configuration file. If it's something else, you can either (ab)use the OVERRIDE mechanism (:my-beaglebone) to specify packages to install only for one machine. E.g. in your image recipe:
IMAGE_INSTALL:append:my-beaglebone = " some-my-beaglebone-package"
If you want the same package but in different version or a different implementation (e.g. dropbear vs openssh, barebox vs uboot), have a look at virtual recipes (you can find consumers of those virtual recipes where virtual/somthing is used).
Finally, it might make more sense to just have multiple image recipes, each machine having its own image recipe for example.
Remember, distro is for policy (should my system be configured to run with x11, wayland, alsa, whatever), machine is for HW and recipes are for SW applications configured for a given policy and compiled for a given machine. If your HW is identical but you want some differences in your images, you might want to have a look at distro configruation files rather than different machines (at least on the theoretical and best practice level, it's the preferred way).