There are many kernel *.bb in
~/poky/meta/recipes-kernel/linux
I don't have PREFERRED_PROVIDER_virtual/kernel defined in local.conf
I also include meta-intel layer, I think meta-intel has it's kernel recipe also.
After built the yocto image, boot, and login, type 'uname -a' result is
Linux genericx86-64 5.4.20-yocto-standard xxxxx
I think yocto select it's poky kernel, but I can't find where this default setting located. ( which file setting this kernel )
Usually you can find it in the machine conf in :
meta-yourmeta/conf/machine/yourmachine.conf
The list of supported kernels by your machine is in recipes-kernel of your BSP.
It's set by MACHINE, if I'm not wrong.
If you are unsure of your setting of PREFERRED_PROVIDER_virtual/kernel you can also use bitbake -e <recipe> to see how it is set.
Poky itself has it defined with default value
poky/meta/conf/machine/include/qemu.inc:22:PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
poky/meta/conf/machine/include/x86-base.inc:20:PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
Related
I am using an embedded Linux system based on Yocto/Open Embedded Linux and the systemd-journald-remote program is missing.
When I look at the systemd recipe the program is mentioned. It seems like it is not compiled or added by default to the image. I understand how to add normal recipes but unfortunately I don't understand how to add such a "subpackage".
The Bitbake documentation is unfortunately overwhelming for a beginner like me. Can someone help me?
Create bbappend for systemd in your meta-layer with following path recipes-core/systemd/systemd_%.bbappend and:
PACKAGECONFIG_append = " \
microhttpd \
"
You can add it into your image .bb or .bbappend file with following parameter:
IMAGE_INSTALL += "systemd-journal-remote"
This will add systemd-journal-remote into your image. Install the image on your target board, log in to your target and configure the file /etc/systemd/journal-remote.conf.
Then, enable the service with systemctl enable systemd-journal-remote, and then restart it with systemctl restart systemd-journal-remote.
I am building linux system for raspberrypi4 but for some reason I need to remove getty#tty1 service in yocto.
I have created systemd_%.bbappend file for that.
Host PC is Ubuntu 18.04
this is working with warrior branch
Now, I am trying to compile with dunfell branch in yocto
but at the time of systemd compiling it gives an error like
"cannot remove /etc/systemd/system/getty.target.wants/getty#tty1, no such file or deirectory
But at the end, In final image there I can see getty#tty1.service
Also I can't find any other receipe that creates this link.
systemd_%.bbappend looks like this
DESCRIPTION = "Customization of systemD services."
do_install_append() {
rm ${D}${sysconfdir}/systemd/system/getty.target.wants/getty#tty1.service
}
FILES_${PN} += "${sysconfdir}/systemd/system"
REQUIRED_DISTRO_FEATURES= "systemd"
Thanks
Margish
On more recent versions of systemd (like the one in Yocto dunfell), the links to services are not created by the build system (ninja), but instead by running systemctl preset-all on the running system after installation (see here). This command reads the systemd preset files to determine which units to enable or disable by default.
In Yocto, what this means is that instead of the links being created as part of the systemd recipe, systemctl preset-all is run as part of the IMAGE_PREPROCESS_COMMAND during image creation in image.bbclass (see here). This is why the old method of deleting the symbolic links in /etc/systemd/system from the systemd recipe no longer works.
Instead, what you need to do is modify the 90-systemd.preset file to disable the getty#tty1 preset (or any other default system service) by changing the below line:
enable getty#.service
to this:
disable getty#.service
You can accomplish this using a bbappend file as follows*:
# systemd_%.bbappend
do_install_append() {
# Disable getty#tty1 from starting at boot time.
sed -i -e "s/enable getty#.service/disable getty#.service/g" ${D}${systemd_unitdir}/system-preset/90-systemd.preset
}
*https://stackoverflow.com/a/67505478/286701
I would like to change the init system on a per-image basis.
I have created a sample image as pointed out here.
This works well, but I also want to remove the unused init system (in this case SysVinit) from rootfs.
Therefore I tried something like this inside my distro config: (REQUIRED_DISTRO_FEATURES = "systemd" is set inside my image.bb)
DISTRO_FEATURES_BACKFILL_CONSIDERED = "${#bb.utils.contains('REQUIRED_DISTRO_FEATURES', 'systemd', 'sysvinit', '', d)}"
Finally it results into this, exactly what I expect:
$ bitbake sample-image-systemd -e | grep DISTRO_FEATURES_BACKFILL_CONSIDERED=
DISTRO_FEATURES_BACKFILL_CONSIDERED="sysvinit"
So far so good. But the final rootfs still contains sysvinit scripts (/etc/init.d/*)
If I do the following inside my distro config everything works well and /etc/init.d is not created:
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
So I don't really understand the difference and why my solution doesn't work.
The difference is that that systemd recipe does not have a dependency to your recipe which is good because if it had it would be a circular dependency. So, variables defined in your recipe are not expanded or accessible by the systemd recipe
Now to better explain this you can run the following command.
$ bitbake systemd -e | grep DISTRO_FEATURES_BACKFILL_CONSIDERED=
The result should be
DISTRO_FEATURES_BACKFILL_CONSIDERED=""
This happens because the sample-image-systemd recipe variables are not expanded and used while you are building/packaging/etc the systemd recipe. To make a variable global or accessible by all recipes you should add it to your distro config or your local config.
I'm trying to add auditd to Yocto linux.
I added the selinux layer and it's dependent layers: openembedded-core and meta-virtualization.
I added the layers to bblayers.conf.
I added DISTRO_FEATURES_append = " acl xattr pam selinux"
and PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls" to the local.conf file.
After building (by using bitbake core-image-base) and running the qemu, the kauditd process is running, but all user-space tools are not.
The /etc/audit folder is not exist ,non of the audit's config files exists (audit.rules) and no user-space audit process is running.
In the layer's info it is declared - "User space tools for kernel auditing".
What I am missing?
Thanks.
I think I found something that will answer your question: If you know what an example binary or library you expect to be in the target image, you can find what recipe the executable is in, and then add that package to the image.
Start with the name of a binary or library you expect to be in the image and run the following. For me, I am using a CAN bus executable called candump. I wonder what recipe it's in? To find out, I issue:
devtool search candump
Which returns:
can-utils
If nothing is returned, I'd double check your conf/bblayers.conf so that the layer you think it may be in is actually being seen by your build system. If you are unsure, take a look at the link below which points to OpenEmbedded which has a handy search utility for packages.
After you find the recipe, you can then include that recipe into your build.
Here is a good reference in doing what I think you're asking on the OpenEmbedded website:
https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image
I just added auditd to my system. This is what I did.
First I got the repository checked out.
cd /path/to/yocto
git clone git://git.yoctoproject.org/meta-selinux
cd meta-selinux
# checkout the branch matching the Yocto release you are on
git checkout thud
Then I added auditd to my build.
cd /path/to/build
bitbake-layers add-layer /path/to/yocto/meta-selinux
cat >> conf/local.conf <<'END'
IMAGE_INSTALL_append = " auditd"
END
bitbake my_normal_image_target
Even though the Yocto recipe is called audit, the package name is auditd.
Of course, auditd without selinux is useless but it did attempt to run (journalctl -u auditd) and /etc/audit exists.
FWIW: To get auditd to a point where it reports say, login success/failure, I had to do a few more things. I'm not just adding it to a standard Yocto image, but to a custom image and custom machine. I'm already using systemd so I didn't have to change that (the layer seems to indicate it's required?). My local.conf looked like this.
# enable selinux
DISTRO_FEATURES_append = " acl xattr pam selinux"
# set the policy
PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
# install selinux packages and auditd
IMAGE_INSTALL_append = " packagegroup-core-selinux auditd"
# tell the kernel to enable selinux (non-enforcing) and audting
APPEND_append = " selinux=1 enforcing=0 audit=1"
I also had to change linux-yocto_selinux.inc to load selinux.cfg later. Probably layer/recipe ordering could have solved this too?
-SRC_URI += "${#bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}"
+SRC_URI_append = "${#bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}"
With all that in place, I see audit logs in my journal.
I would like to create a new target based on core-image-minimal and I would like to change the init system with systemd over SysV init. I would like my change to be permanent (nothing based on local.conf). How can I do this?
Edit: As Anders pointed out in the comments, i was wrong:
The available init systems are set in the local.conf, but you can indeed change the init system on a per image basis. In your case you want to change it in core-image-minimal. This image installs packagegroup-core-boot which sets
VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
VIRTUAL-RUNTIME_initscripts ?= "initscripts"
You could create your own packagegroup-core-boot-systemd where those variables are set to
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
and install it to your target.
The configuration of the init system is a Distro Feature. That means it is not in the image recipe, but in the local.conf.
If you don't want to put the configuration in the local.conf, you could create a custom distro configuration with the settings in it. The only thing you have to change in the local.conf is the line
# DISTRO = poky
DISTRO = <custom-distro>
The reference manual has also a chapter on creating your own distro