I have built an image with systemd and dhcp-client. In the recipe dhcp in meta-openembedded/meta-systemd/oe-core/recipes-connectivity/dhcp there is a bbappend which creates a dhclient.service. I want to modify (or override) this file but when I launch bitbake, I have an error which tells me Applying patch 0001-dhclient-modify-interface.patch can't find file to patch at input line 5.
Here is my patch for dhclient.service :
Index: 4.3.3-r0/dhclient.service
===================================================================
--- 4.3.3-r0.orig/dhclient.service
+++ 4.3.3-r0/dhclient.service
## -6,7 +6,7 ## After=syslog.target network.target
Type=forking
PIDFile=/var/run/dhclient.pid
EnvironmentFile=-/etc/default/dhcp-client
-ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient.conf -q -lf /var/lib/dhcp/dhclient.leases $INTERFACES
+ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient.conf -q -lf /var/lib/dhcp/dhclient.leases eth0
[Install]
WantedBy=multi-user.target
And my dhcp_%.bbappend :
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://dhclient.service"
I also tried to override the file, but it seems to completly ignore my file...
I want to enable this by default but how can I override this ligne (present in the dhcp folder) to enable : SYSTEMD_AUTO_ENABLE_dhcp-client = "disable"
Well, you can't easily patch the file, as it's not part of the source.
However, it should be enough to add a .bbappend with
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
SYSTEMD_AUTO_ENABLE_dhcp-client = "enable"
and the put dhclient.service in your layer at recipes-core/dhcp/dhcp/dhclient.service.
This assumes that your layer has a higher priority as compared to meta-systemd.
There is another solution that works for me is first disable the original bbappend and then add your own ones.
Put BBMASK = "meta-openembedded/meta-systemd/oe-core/recipes-connectivity/dhcp/original.bbappend" into your build/conf/layers.conf to disable the original upstream bbappend, then make a new bbappend into your own recipe. That way can "override" the bbappend.
This is more flexible and can be apply to more scenarios not limited by your case.
Related
Whats wrong with the argument,
is there is no kernel_add_dts subcommand.
I get this below error whenever i try to run
$ recipetool kernel_add_dts meta-local /path/to/my.dts
recipetool: error: argument <subcommand>: invalid choice: 'kernel_add_dts' (choose from 'edit', 'create', 'newappend', 'appendfile', 'appendsrcfiles', 'appendsrcfile', 'setvar')
usage: recipetool [-d] [-q] [--color COLOR] [-h] <subcommand> ...
Use recipetool to add a new device tree to your custom layer following this syntax:
recipetool appendsrcfile -wm (MACHINE) (PATH/TO/LAYER) virtual/kernel (PATH/TO/DTS) 'arch/${ARCH}/boot/dts/(YOUR_DTS_NAME).dts'
Details:
(MACHINE): Your build machine name
(PATH/TO/LAYER): The path to the layer that you want the linux-xx_%.bbappend file with the new DTS will be created
(PATH/TO/DTS): The path to the new DTS file
(YOUR_DTS_NAME): The DTS file name
Important note:
If the default device tree name is the same as the one you are adding it is not a problem, if not, please make sure that you add it to KERNEL_DEVICETREE variable so that it will be shipped with all the DTS files in the boot partition.
KERNEL_DEVICETREE += "(NEW_DTS_NAME).dtb"
After that you can stop Uboot (if you are using Uboot) and specify the new DTS file with:
setenv fdt_file (NEW_DTS_NAME).dtb
saveenv (If you want to save it for every boot)
Please run "printenv" to make sure of the "fdt_file" variable's name.
Real run test:
recipetool appendsrcfile -wm imx8mmddr3lval /home/talel/Desktop/final_git/meta-node virtual/kernel /home/talel/Desktop/example.dts 'arch/${ARCH}/boot/dts/example.dts'
...
NOTE: Writing append file /home/talel/Desktop/final_git/meta-node/recipes-kernel/linux/linux-imx_%.bbappend
NOTE: Copying /home/talel/Desktop/example.dts to /home/talel/Desktop/final_git/meta-node/recipes-kernel/linux/linux-imx/imx8mmddr3lval/example.dts
The new bbappend file is:
$ cat /home/talel/Desktop/final_git/meta-node/recipes-kernel/linux/linux-imx_%.bbappend
SRC_URI += "file://example.dts;subdir=git/arch/${ARCH}/boot/dts"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
PACKAGE_ARCH = "${MACHINE_ARCH}"
With "virtual/kernel" it will detect what provides it (linux-imx, linux-yocto, ...) and it will create linux-imx_%.append file.
The -w flag will create "_%" as for any version number.
Solution to avoid any patch for the DTS file:
If there is patches for your Linux kernel they will fail if you are updating the DTS with new modifications that override some lines that the patch expects, so you can do it cleanly in 2 ways:
bitbake virtual/kernel -c cleansstate
bitbake virtual/kernel -c patch
Now all patches are applied, go to tmp/work/../linux-(PROVIDER)/../git and:
git add .
git commit -m "commiting old patches"
Now edit the DTS file and:
git add arch/../boot/dts/../myplatform.dts
git commit -m "changes"
git format-patch -1 -o /path/to/meta-custom/recipes-kernel/linux/files
Now add it to /path/to/meta-custom/recipes-kernel/linux/linux-(PROVIDER)_%.bbappend:
SRC_URI_append = " file://patch_file.patch"
Or, the other way is to add your final DTS after the patch is done:
SRC_URI_append = " file://myplatform.dts"
do_configure_append(){
cp ${WORKDIR}/myplatform.dts ${S}/arch/(ARCH)/boot/dts/....
}
and copy your myplatform.dts to /path/to/meta-custom/recipes-kernel/linux/files.
Now, that's your final DTS file.
Remove what recipetool added:
Actually, no undo subcommand in recipetool, you just need to delete the files that recipetool deployed, recipetool copy the file you specified and create a bbappend file, so remove those two files.
Example: you used recipetool to add example.dts file, recipetool copied example.dts to:
meta-custom/recipes-kernel/linux/(MACHINE)/example.dts
and created bbappend file in which it added example.dts to SRC_URI variable.
If you need to keep the bbappend file because you are using it in other way, just modify it and remove the line added by recipetool which contains:
SRC_URI ... "file://example.dts ..."
I am experimenting with Yocto project for generating custom Linux images for my embedded devices.
I have a requirement to add a persistent custom kernel parameter to /etc/sysctl.conf of the generated image.
i.e.
kernel.core_pipe_limit = 1
/etc/sysctl.conf is generated by procps package that comes with Yocto base system (meta/recipes-extended/procps/procps/sysctl.conf). However, I believe editing the sysctl.conf in the base system is not the recommended approach.
I am using a new layer for defining my custom configurations. I hope there is a way to apply a patch to a base package via a custom layer after deploying the base layer.
How can I do this?
I am aware how to persistently change a kernel variable by updating /etc/sysctl.conf (or, preferably, /etc/sysctl.d/xxx.conf). My question is, how to generate the Linux image with the necessary update applied?
You can add something like this in image recipe or local.conf:
set_kernel_opt(){
mkdir -p ${IMAGE_ROOTFS}/etc/sysctl.d
echo 'kernel.core_pipe_limit = 1' > ${IMAGE_ROOTFS}/etc/sysctl.d/kernel_core_pipe_limit.conf
}
ROOTFS_POSTPROCESS_COMMAND += "set_kernel_opt;"
If you want to override /etc/sysctl.conf file, you can create a meta-custom/recipes-extended/procps/procps_%.bbappend file with:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
Then create a folder meta-custom/recipes-extended/procps/files and copy your custom sysctl.conf file in it.
Finally you can create a meta-custom/recipe-custom/custom-config/custom-config.bb recipe with:
LICENSE = "CLOSED"
SRC_URI = " \
file://kernel_core_pipe_limit.conf \
"
PV = "1.0"
S = "${WORKDIR}"
inherit allarch
do_install() {
install -d ${D}${sysconfdir}/sysctl.d
install -m 0644 ${B}/kernel_core_pipe_limit.conf ${D}${sysconfdir}/sysctl.d/
}
do_configure[noexec] = "1"
do_compile[noexec] = "1"
And copy your kernel_core_pipe_limit.conf in meta-custom/recipe-custom/custom-config/files/
The answer up there are wrong in my opinion. There is already a recipe providing sysctl.conf. It is procps. What you need to do is override the default configuration with a bbappend. More about append files on the online Yocto documention
Create a procps folder, procps_%.bbappend and systctl.conf in recipes-extended in your layer such as
meta-my-layer/recipes-extended/
└── procps
├── files
│ └── sysctl.conf
└── procps_%.bbappend
procps_%.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"`
(example of) sysctl.conf:
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
In case you want to keep default configuration and append to it, you only need a do_install_append step with an echo appending your text.
Just create a file with .conf extension under /etc/sysctl.d.
echo 'kernel.core_pipe_limit = 1' > /etc/sysctl.d/bla_bla_change_kernel_core_pipe_limit.conf
From man sysctl:
--system
Load settings from all system configuration files. Files are
read from directories in the following list in given order
from top to bottom. Once a file of a given filename is
loaded, any file of the same name in subsequent directories is
ignored.
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
The sysctl --system should be called on system startup. On systems with systemd this is done via systemd-sysctl.service service. Thus it should load all the /etc/sysctl.d. The syntax is the same as /etc/sysct.conf syntax files.
I am new, yocto build at imx6q embedded system.
I want to overwrite linux system files after do_rootfs. For example, target system files are below.
/etc/network/interface
/etc/issue
/etc/init.d/rcS
/home/root/mytest.sh
so, i made custom layer and custom recipe.
helloworld binary is copy ok.
but, do_mytask function is not called.
what's wrong with my code?
or any other method for my purpose.
#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#
SUMMARY = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://helloworld.c"
S = "${WORKDIR}"
do_compile() {
${CC} helloworld.c -o helloworld
}
do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += " \
file://interfaces \
file://issue \
file://mytest.sh \
"
addtask mytask after do_rootfs before do_image
do_mytask() {
install -d ${D}/etc/network
cp -af ${WORKDIR}/interfaces ${D}/etc/network/interfaces
cp -af ${WORKDIR}/issue ${D}/etc/issue
}
You'll need to extend the recipes that provide the files you want to replace.
Using /etc/network/interfaces as an example, the first step is to figure out which recipe installs that file.
From the bitbake prompt:
$ oe-pkgdata-util find-path /etc/network/interfaces
init-ifupdown: /etc/network/interfaces
So this tells us that /etc/network/interfaces is installed by the init-ifupdown receipe.
A file search shows that init-ifupdown is part of poky:
$ find . -name init-ifupdown*.bb
./poky/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
Now, since you need to modify the output of init-ifupdown, you'll need to extend init-ifupdown by creating a similarly named .bbappend in your own layer.
You might create the new .bbappend at
my-layer/receipes-core/init-ifupdown/init-ifupdown_%.bbappend
The % is a wildcard that ensures the .bbappend will apply to all future versions of the init-ifupdown recipe, which is probably what you want.
Place your custom interfaces file in a folder below the .bbappend:
my-layer/receipes-core/init-ifupdown/files/interfaces
The .bbappend then only needs to contain a single line to enable bitbake to pick up the new interfaces file:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
Finally, repeat the above with each system file you'd like to replace.
It depends on the file to modify. For example, if you search 'interfaces' in poky directories, you'll find it in 'meta/recipes-core/init-ifupdown/init-ifupdown-${PV}/'. You just need to create a recipe named init-ifupdown-${PV}.bbappend in your meta, recreating the path seen in poky (recipes-core/init-ifupdown/). This recipe can contain a single line :
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
Then you create a 'files' folder with the 'interfaces' file you want to have.
For 'issue', like others found in the /etc directory (profile, fstab, ...), it's the same procedure, with the sources in poky/meta/recipes-core/base-files/.
For init.d scripts, use the 'update-rc' class.
You recipe is not "image recipe" (and it shouldn't be for hello world) thus you cannot use tasks do_rootfs and do_image in this case. A bit of clarification: image recipe is .bb file that you use to build image with bitbake or devtool (in your case some containing imx6q, you can find them with bitbake-layers show-recipes "*-image-*").
It looks like you are looking really is a way to override do_install of some recipe that installs that mentioned files. Then find what recipe installs those files and create bbappend file in your top layer. This bbappend file may contain do_install_append task where you can place your install <file> <dir> lines (note, using cp as not recommended, everything should be done with install tool).
Adding an extra comment based on Carsten Hansen original answer for folks working with Xilinx/Petalinux.
Under Petalinux environment we don't really have the command: oe-pkgdata-util, so the strategy is to do a search in the Xilinx SDK folder. You might have it installed on Linux under /opt according to the documentation. If you do a:
grep -r syslog-startup.conf .
you will see busybox recipe being the one that does the installation of the syslog-startup.conf.
You can create the override recipe called busybox_%.bbappend under:
../project-spec/meta-user/recipes-core/busybox/
Put the modified syslog-startup.conf file under:
../project-spec/meta-user/recipes-core/busybox/files/syslog-startup.conf
Rebuild via petalinux-build. You can also force the creation of the rootfs via petalinux-build -c rootfs and the system should populate your new file.
I tried to include my custom helloword patch to build root.
in
make menuconfig
I have added global patch directory /home/Downloads/buildroot/buildroot-2017.11/patches
and I place my patch files inside the below directory
(/home/Downloads/buildroot/buildroot-2017.11/patches/packagename/version/patch).
I referred this link and this link
After make command the patch is not getting applied in my source directory, the source is getting extracted to the output/build directory from the .tar fle.
please suggest a solution..
Config.in
config BR2_PACKAGE_HELLOWORLD
bool "helloworld"
help
Hello World package says hello world to you
see http://helloworld.com for more on this software
helloworld.mk
HELLOWORLD_VERSION = 1.0.0
HELLOWORLD_SOURCE = helloworld-1.1.tar.gz
HELLOWORLD_PATCH = 18-helloworld-testing.patch
HELLOWORLD_SITE_METHOD = local
define HELLOWORLD_BUILD_CMDS
$(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(#D)
endef
define HELLOWORLD_INSTALL_TARGET_CMDS
$(INSTALL) -D -m 0755 $(#D)/helloworld $(TARGET_DIR)/usr/bin/helloworld
$(INSTALL) -D -m 0755 $(#D)/helloworld-init $(TARGET_DIR)/etc/init.d/S90helloworld
endef
$(eval $(generic-package))
With the local _SITE_METHOD, patches are not applied. local is when you want to use the files directly from their source directory. With the local _SITE_METHOD, the directory specified in HELLOWORLD_SITE will be copied to the build directory, no patches are applied, the _SOURCE is not used.
However, since you don't specify HELLOWORLD_SITE, you trigger a corner case that causes it to behave like the file _SITE_METHOD (which is the one you actually want). Buildroot should give an error for this case. A patch is pending for this.
Unfortunately, that doesn't explain why the patches don't get applied.
*I have read the previous answers like below
INHERIT += "extrausers"
EXTRA_USERS_PARAMS = "usermod -P p#ssw0rd root;"
if I add the above line in my local.conf I cannot create a patch.
So I need guidance to set a default password to root. I found a path in poky below ,which file I need to change. and what can I change.
/home/..../sources/poky/meta/recipes-extended/shadow*
I think it is not a good idea to modify the default meta files. To add users you can modify your image recipe and simply add:
inherit extrausers
EXTRA_USERS_PARAMS += "usermod -P p#ssw0rd root;"
The location of your image recipe depends on your setup, it will probably be in your custom meta.
I used to modify shadow file manually
ROOTFS_POSTPROCESS_COMMAND += "change_root_psw;"
change_root_psw() {
sed 's%^root:[^:]*:%root:<encrypted_password_goes_here>:%' \
< ${IMAGE_ROOTFS}/etc/shadow \
> ${IMAGE_ROOTFS}/etc/shadow.new;
mv ${IMAGE_ROOTFS}/etc/shadow.new ${IMAGE_ROOTFS}/etc/shadow ;
}
Encrypted password can be retrieved directly from shadow file.