I have included meta-selinux layer in my project source code. As audit is already present in meta-selinux/recipes-security/audit, have added this audit recipe to my yocto image by IMAGE_INSTALL_append = " audit" in machine specific conf file, but when I compile image(core-image-sato) and flash it on device, I do not see any user space audit process running. I need audit to figure out SELinux violations and other debugging purpose.
Why 'audit' is not getting installed in yocto image(core-iamge-sato)?
I know I can see SELinux violations messages in /var/log/messages but I want to have user space audit running on my device so that I can debug better
Thanks for time !!
Can you check meta-selinux is included in bblayers.conf. Check your build-***/conf/bblayers.conf. Then include the audit package in build-***/conf/local.conf.
IMAGE_INSTALL_append = " audit"
Then build audit package and check its built successfully. Then build the core-image-sato and flash the image.
You need to include auditd
like: IMAGE_INSTALL_append = " audit auditd"
Related
I have a project that is mostly complete for a custom third party SoM which requires custom bootstrap/bootloaders, currently the recipe is in a meta-bsp layer which works alright however they are built in the aarch64-poky-linux build directory. We have multiple SoM models from this manufacturer that each require different bootloader configs and I'd like them to be built in a machine specific non-linux directory if possible like aarch64-<machine>-none or something. Is this possible?
We are using dunfell release.
Recipes are in meta-mfg/recipes-bsp/mfg-/mfg-_version.bb
Fairly standard recipe setup including:
SECTION = "bootloaders"
SRC_URI..
DEPENDS (native packages only)
do_configure()
do_compile()
do_install()
Current build directory: tmp/work/aarch64-poky-linux/mfg-bootloader/1.x.x-rx/
Preferred build directory: tmp/work/aarch64-<machine>-none/mfg-bootloader/1.x.x-rx/
When building for different machines/soms it uses the same directory and uses the previous build which may be incorrect. We do have a workaround where we don't stamp the configure/build/install tasks so they always rebuild however we'd like a cleaner more appropriate implementation.
Is there any way to accomplish this?
I haven't been able to find any information so far.
I have been pointed to the solution from the IRC channel for anyone with the same question:
Add PACKAGE_ARCH = "${MACHINE_ARCH}" to the recipe to build in machine specific folders.
I just added a new package to my Yocto build (this one: How do you properly build gpiod applications from Yocto?), and it works fine as long as I am connected to the internet. The problem is that I am now trying to make the tarball needed to support an offline build.
A little bit about the setup: I am running Yocto Zeus. I work in a VM (Ubuntu 18.04) connected to the internet, but our build agents are not on the network, so we host a mirror. I have this mirror mounted on /mnt/download-mirror. I am trying to generate the tarball needed for the mirror on my VM.
This is the Yocto config that I am using:
BB_NO_NETWORK = "0"
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "file:///mnt/download-mirror"
UNINATIVE_URL = "${SOURCE_MIRROR_URL}/uninative/2.7/"
BB_GENERATE_MIRROR_TARBALLS = "1"
SSTATE_MIRRORS = "file://.* file:///mnt/sstate-mirror/PATH"
But when I run Bitbake (I using command bitbake --runall fetch) it completes, but I don't get a tarball for the new package I added. I have looked for this tarball in the poky-downloads folder (the folder I would normally rsync to the mirror server), but it doesn't appear to be there.
Am I missing a configuration or something? I have all the configurations noted in https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3f
EDIT - I also tried setting DL_DIR ?= "/home/gen-ccm-root/Downloads" in my conf file, but my command still said there was nothing to do, so I think the issue might be my bitbake command. I have also tried bitbake -c mi-dev --runall="fetch" where mi-dev is my target (per 7.23.2 in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#setting-up-effective-mirrors) to no avail.
Hopefully someone can edit this and put in more information as to why, but I did manage to get it to generate a tarball.
Cleaned my VM which entailed deleting the sstate-cache and poky-downloads.
Modify the local.conf to have the following at the end (I think the DL_DIR is optional):
BB_NO_NETWORK = "0"
DL_DIR ="/home/gen-ccm-root/Downloads"
BB_GENERATE_MIRROR_TARBALLS = "1"
Run command: source oe-init-build-env build-dev
Run command: bitbake mi-dev --runonly=fetch
Mount the network share containing the download mirror.
Copy the files over:
sudo rsync -av --ignore-existing --exclude=*.done --exclude=git2 --exclude=svn /home/gen-ccm-root/Downloads/ /mnt/download-mirror/
I will update this as I learn more (I am still kind of a Yocto noob), but the issue appears to be related to a combination of Yocto not reparsing after changing the config, and the fact that the sstate-cache was still accessible and said everything was there.
Wait a bit, with BB_NO_NETWORK it should not go out and fetch stuff from the internet.
If I understand it correctly you want a source mirror for some other build machines locally.
One way would be to share your DL_DIR of the one machine, which sees the internet.
Another way would be to use a source mirror for which you need the BB_GENERATE_MIRROR_TARBALLS = "1" from above.
I use a web server to export my DL_DIR (which also contains the tarballs) and on the machines which should use it I use e.g. in local.conf or site.conf:
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "http://mirror/source_mirror_zeus"
Just as a hint besides the sources you could also export SSTATE via SSTATE_MIRRORS, which will decrease build time a lot.
I have a yocto image into which I have included the CUPS package (using IMAGE_INSTALL_append).
While running the OS, I couldn't find the cups file in /etc/init.d.
I started cups using cupsd. When I tried accessing the web interface using localhost:631, I got a not found error. The console shows that it is not able to load resources on any of those URLS:
http://localhost:631/cups.css
http://localhost:631/
http://localhost:631/favicon.ico
The html and related files seem to be listed in the cups.inc file. Are there additional configuration changes that need be made before doing the YOCTO build or on the CUPS setup?
Since I am very new to yocto and developing in a linux environment, I am not sure if I am missing something obvious.
This question is quite old and already has an accepted answer. Nevertheless, it may be of use for someone else facing the same problem of missing static html content of the CUPS Web interface.
The CUPS recipe packages the static web content into cups-doc.
Thus, instead of
IMAGE_INSTALL_append = " cups"
it should be
IMAGE_INSTALL_append = " cups cups-doc"
in your conf/local.conf.
Then, also the files under /usr/share/doc/cups were added to the rootfs.
Check
# Replace <target>, <image> and <version> to match your configuration
# e.g.: raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0
$YOUR_POKY_DIRECTORY/build/tmp/work/<target>/<image>/<version>/rootfs/usr/share/doc/cups
that was entirely missing before adding the cups-doc package.
You made good research pointing to the recipe and were actually close to find the solution.
In the recipe, you can read:
# Remove sysinit script and symlinks if sysvinit is not in DISTRO_FEATURES
if ${#bb.utils.contains('DISTRO_FEATURES','sysvinit','false','true',d)}; then
rm -rf ${D}${sysconfdir}/init.d/
rm -rf ${D}${sysconfdir}/rc*
fi
Is sysvinit in your DISTRO_FEATURES?
If you don't know you can do
bitbake cups -e | grep "^DISTRO_FEATURES="
I like to disable and enable some pins in my RPi project.
These are GPIO 6, GPIO 5 and GPIO 26. I like to use these PINs in my own kernel driver.
For this project I connect a simple electric board via the GPIOs. The minimal system is build via yocto. I like to change the device tree file to disable/enable GPIOs.
I need to change or make my own dts file. For that I think I will need to:
find the original RPi dts
patch it or create my own dts
add it to the layer.conf
add file to the kernel recipe via append
How can I do this? or where can I find the sources?
Actually I am struggling to find the dts files for the RPi2 I am using. I was checking the "raspberrypi2-poky-linux-gnueabi" recipe results(and do not find any files).
I do not find any tutorial how to setup yocto + meta-raspberrypi + own dts. it would be great if we can figure out the necessary steps.
I'm not convinced this question has been well answered, so let me take a few minutes and document what I've done to add device tree overlays to my yocto builds.
This is a multi-problem process.
I'm going to make a few assumptions:
* You source your oe-init-build-env in a shell, and do your bitbake builds manually in a terminal (or you know how to do it with equivalent tooling)
* You know (or are already learning) the basics of device trees...
Start with your own meta layer. Mine is out on github.
You'll need to create an *-overlay.dts source file. You can start with a simple place holder, and stuff it (quite literally) anywhere on your system. We'll import it to your meta layer in the next step using bitbake to do some of the staging and what-not for us.
recipetool appendsrcfile -wm rpi /path/to/your-layer-meta virtual/kernel /path/to/your-overlay.dts 'arch/${ARCH}/boot/dts/overlays/your-overlay.dts
At this point, you should end up with a recipes-kernel/linux directory with an appropriate bbappend targeting the $MACHINE type of -wm (rpi, as above), ready to copy the device tree source file into the proper spot for bitbake to find it when it building the kernel. But it still won't be included in your kernel build.
We need to add the overlay reference to the KERNEL_DEVICETREE variable, in places that will cover the scopes of: linux, bootfiles, and the sdcard_image-rpi.bbclass from meta-raspberrypi.
In the linux bbappend created in step 3, add KERNEL_DEVICETREE += "overlays/your-overlay.dtbo" to make the linux kernel build include your dts as something to compile into a dtbo.
To make the sdcard_image-rpi.bbclass copy the file, you'll need to add KERNEL_DEVICETREE =+ "overlays/your-overlay.dtbo" to your image recipe.
To make the overlay active, you'll need to create a recipes-bsp/bootfiles/rpi-config_git.bbappend whereyou can append a do_deploy step to add the dtoverlay=your line to config.txt.
I use my layer for more than one project, so I felt OK with having the dts compile with every kernel but only copy it to images where my image recipe added it to the KERNEL_DEVICETREE. For further insurance that I don't get these things interferring in images I don't want them in, my rpi-config append has a test to see if I should add the dtoverlay line to the config.txt
Of course, this was all assuming you were going to use your own home-grown DTS without starting from a kernel-sourced one. The process would be largely the same, but you'd be able to patch the existing, or copy it, or whatever you want to do in your linux recipe.
I hope this helps! I know it's an old question.
First you need to find the kernel used on your yocto project, the recipe is linux-raspberry.bb or something like linux-*.bb. The preferred kernel is probably set in your local.conf or machine.conf: PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberry"
This is indirectly set via "meta-raspberrypi/conf/machine/include/rpi-default-providers.inc" which is included via "rpi-base.inc"
Once found, take a look at the recipe, clone the git repository of the kernel, on the right branch, and reset at the right SRCREV.
Once downloaded, the dts files are in /path/of/my/kernel/linux-raspberry/arch/arm/boot/dts/. You can find the name of the devicetree file used in the kernel recipe, local.conf or machine.conf, with the variable KERNEL_DEVICETREE = "..."
For the meta-raspberry and rpi2 selected, the dts files can be found in <path to build dir>/linux-raspberrypi2-standard-build/source/arch/arm/boot/dts/. The source dir is a linked dir to the git sources.
You can add a new dtb by creating dtsi/dts files (don't forget to add it in the Makefile).
Create a patch, add it to the kernel recipe:
SRC_URI += "file://0001-mypatch.patch"
and put the patch file like this in your meta
├── files
│ └── 0001-mypatch.patch
└── linux-raspberry.bb
Modify the KERNEL_DEVICETREE variable to add your new dtb.
Now you can bitbake your kernel/image, your new dtb will be created.
I am trying to remove some open source packages that have GPLv3 licensing attached to them that we cannot distribute as part of the final production image . While these packages can be removed using "INCOMPATIBLE_LICENSE=GPLv3" in local.conf but it removes every package that's tagged GPLv3.
I have used
PREFERRED_VERSION_recipename=(GPLv2 recipe_version)
and downgraded all the GPLv3 packages to GPLv2 that we want to push into the final image. But there are several GPLv3 packages that we want to keep as part of the debug image for example M4, make, gdb, bison. There is no need for these packages to be in the final production image but these cannot be removed from the build completely as they are needed during the build/debug.
SO, How do i remove these packages/recipe from the final rootfs image while letting them being as part of the build process and letting them build. In other words I want to let the bitbake build them from the GPLv3 source but keep them out the of the final rootfs image.
I did look at the poky/lib/oe/manifest.py and rootfs.py create function ==> where the final rootfs manifest is being created but couldn't figure out what exactly needs to be set from the bitbake. Does the do_rootfs need to be overwritten. if so what variables need to be set for overriding the final manifest.
There's no single way of doing what you want. One way is to have your production image consists of what you need to deliver, and then let your dev-image require production-image.bb. In that way you can easily extend the dev image with your extra packages.
I've got a similar issue, as I want gdbserver in my dev-image. (Sofar, nothing else that's GPLv3 is necessary / wanted in my dev image). What I've done, is to set
INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
INCOMPATIBLE_LICENSE_pn-gdb = ""
That basically allows gdb to be built, but nothing else that's GPLv3 licensed. Then, my images inherit a company-image.bbclass instead of directly inheriting image.bbclass. In company-image.bbclass, I've got a function like:
python () {
for p in d.getVar('IMAGE_INSTALL', True).split():
if p in ['gdb', 'gdbserver'] and not d.getVar('IMAGE_BASENAME', True) == 'company-dev-image':
bb.fatal("gdb/gdbserver is not allowed in this image!")
}
That will ensure that gdb and gdbserver can only be installed in company-dev-image; thus, there's no risk of having them distributed in the production image.
I would like to provide an example that is , if we would like to remove the "openssh" package from build, needs to be updated "local.conf" file as mentioned below.
Please the add the following line into BUILDFOLDER/conf/local.conf file
PACKAGECONFIG_remove = "openssh"