I have built initramfs which I want to use for setting up dm-verity. For testing purposes I don't switch_root and after boot it stays in initramfs. However I need the tool veritysetup. I have it precompiled and copied to /usr/sbin on initramfs, but when I run it on the platform it says - /bin/sh: /usr/sbin/veritysetup: not found. Any ideas how to make it execute?
Yes, I have done this.
For a hint let me first give a simple clue first.
For veritysetup command to work in your initramfs you also need to copy all the dependent libraries (same architecture) to your libs folder inside initramfs.
Related
I intend to set some capabilities on binaries included in a Yocto image using "setcap". For some reason the solutions mentioned here did not work for me:
Linux capabilities with yocto
. I have checked that by running "getcap" on my binary within the rootfs creation directory:
getcap ${IMAGE_ROOTFS}/usr/bin/mybinary
does not return anything. Nor do I find the capabilities in the final running sdcard image.
Next I tried the approach using IMAGE_PREPROCESS_COMMAND. I wrapped up setcap commands in small shell functions such as:
my_setcap_function() {
sudo setcap cap_ipc_owner+ep ${IMAGE_ROOTFS}/usr/bin/mybinary
}
and append the function names to IMAGE_PREPROCESS_COMMAND. This works to the extent that now running getcap on my binary within the {IMAGE_ROOTFS} directory does show the correct caps set. However I still do not get the capabilities in the final running sdcard image.
Also if I mount the rootfs ext4 (which is used to create the final sdcard image) on a directory using -o loop, I do not see the capabilities on my binary.
It seems to me that the capabilitiess somehow get lost when the ext4 is created using mkfs.ext4.
I had to attach sudo to setcap because otherwise it complains saying "unable to set CAP_SETFCAP effective capability: Operation not permitted". Although my understanding was that IMAGE_PREPROCESS_COMMAND commands are run using fakeroot so this sudo should not be required.
So, to summarize my question:
How can I get the capabilities on the sdcard image made using ext4 rootfs image?
I want to use a way that does not require using "sudo".
I am using Yocto Krogoth and currently cannot upgrade that.
Did you really test it on the final image or in the rootfs folder from the yocto build?
I run getcap on the files in the rootfs folder, and there where nothing set.
Because yocto uses pseudo lib to intercept chown, chmod calls, track them in a sqlite db (uses LD_PRELOAD for interception).
So this attributes are not set for the files in the "rootfs" folder, however added at image/rootfs creation.
you can use setcap in recipe, you have to add
DEPENDS = "libcap-native"
in your recipe.
I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.
For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.
I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.
Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.
Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.
You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel
My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.
Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full
Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a
self-extracting and self-installing shell script.
Run the shell script (for me it was
tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh),
and agree to the default SDK location (for me it was
usr/local/oecore-i686).
Source the scripts generated by the install script. I use the
following helper script to load the SDK so I don't have to keep
track of the paths involved. You need to source this in each time
you want to use the SDK.
enable_sdk.sh:
#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
echo "Error: you must source this script."
exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi
Copy the defconfig file from your Yocto directory to your kernel
directory (checked out somewhere outside of the Yocto tree) as
.config.
Run make oldconfig in your kernel directory so that the Linux
kernel build system picks up the existing .config.
Note: you may have to answer questions about config options that
are not set in the .config file.
Note: running make menuconfig will fail when the SDK is enabled,
because the SDK does not have the ncurses libraries set up
correctly. For this command, run it in a new terminal that has not
enabled the SDK so that it uses the local ncurses-dev packages you
have installed.
Run make -jN to build the kernel.
To run the new kernel, copy the zImage and ${NAME}.dtb files to
your NFS/TFTP share or boot device. I use another script to speed
up the process.
update_kernel.sh:
#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x
You can also point Yocto to your local Linux repo in your .bb
file. This is useful for making sure your kernel changes still
build correctly within Yocto.
SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"
UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory.
https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell
When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.
Since it can't parse it, there seems to be a problem with patch. How do you patch the device tree? Are you patching it in the .bb file?
If so, check your patch for possible syntax errors, it's very easy to overlook the syntax errors in device tree. You can remove the patch and do it manually from bitbake -c devshell <kernel-name>
If not, please try to do it there and check again. Please share results if any of these helps you.
I am running ubuntu 13.10 on linux kernel version 3.11.0-12.I have to add a system call in this but i am facing a problem. The very first step says that I have to change my current working directory to kernel directory.
I used the command " cd linux-3.11.0-12 " but it is showing that no such file or directory exists. Please tell me where am i going wrong and how do I correct this mistake.
Wait, you want to add a system call to the Linux kernel, but you don't know how to reach the source code? Are you sure you are able to modify, configure, build, install and boot the Linux kernel?
Assuming yes, you need to get the source code of Linux first (for example, by cloning https://github.com/torvalds/linux or just downloading the version you are interested in), extract it somewhere and then cd to the path where you extracted it. Then you can begin modifying to your heart's content.
Perhaps this blog post could help you.
To get the source of the installed kernel on ubuntu, you can use the command [for ubuntu 13.04+ ]
apt-get source linux-image-`uname -r`
and should be typically be placed under /usr/src
Reference:
[1] https://help.ubuntu.com/community/Kernel/Compile
[2] https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
I am going to setup build environment to make my own linux embedded system for AT91SAM9X25 Board. I am using buildroot to do this. The make command build all targets, the first it build toolchain then packages and then rootfs and images of rootfs (tar, cpio ...).
To rebuild rootfs I usually use make clean and then make. The make clean command removes all and including toolchain.
So the first my question is: Is there some way to remake rootfs without building toolchain? It takes a lot of time.
Also I am building linux kernel within buildroot. I have turned on BR2_LINUX_KERNEL [=y] in buildroot. The linux configured to use Initial RAM filesystem, so to build kernel it required image of rootfs (which should be created by buildroot). When I run make under root of buildroot the building fails with error Cannot open 'buildroot-2013.05/output/images/rootfs.cpio'. Because (if I understand correctly) the building sequence is toolchain - pakages - rootfs - linux kernel - images of rootfs. When it tries to build linux kernel the rootfs.cpio image is not created.
So the second question is: How to build linux within buildroot if I want to use Initial RAM filesystem?
Possibly are there more efficient alternatives than buildroot?
Thanks in advance.
The make command build all targets
You do not want to do that (until Buildroot is configured).
You first need to configure Buildroot by specifying the target board.
Per the manual you can start from scratch, or create a Buildroot config file for your AT91SAM9X25 board derived from a similar board such as configs/at91sam9g20dfc_defconfig
Besides the Buildroot config file, you will also need a Linux kernel config file (unless you want to try configuring the kernel from scratch).
The kernel config file for Atmel's eval board with a AT91SAM9x5 is at91sam9x5ek_defconfig
You should also read section 3.4.2. Creating your own board support
So the first my question is: Is there some way to remake rootfs without building toolchain? It takes a lot of time.
The answer depends on how you define "remake rootfs".
If you delete the directory output/images/, then the files of the rootfs are rewritten.
If you delete directories in output/build/, then those packages or subsystems are recompiled from source.
If you configure Buildroot to use your own or an external tool chain, then make clean would not remove them. If you configure Buildroot to install the toolchain it builds outside of its directory, then it may leave it alone during a make clean.
Of course the Buildroot make is smart enough to know what has changed since the last build and what has to be recompiled.
It should be the rare case that you need to delete directories in output/build/ to force recompilation.
So the second question is: How to build linux within buildroot if I want to use Initial RAM filesystem?
You need to properly configure both Buildroot and the Linux kernel.
make menuconfig
Filesystem images --->
make linux-menuconfig
General setup --->
make
More concise information on using Buildroot for AT91SAM9x5 is this Linx4SAM page
Possibly are there more efficient alternatives than buildroot?
There are other tools such as Open Embedded, but describing them as "more efficient" is subjective.
ADDENDUM
how to rebuild rootfs in buildroot
To force the rootfs to be rebuilt (in this case an initramfs) delete three hidden files in the output/build/linux-x.xx.xx directory
.stamp_images_installed
.stamp_initramfs_rebuilt
.stamp_target_installed
Rebuild rootfs in buildroot
View dependencies:
make show-targets
Example output:
rootfs-cpio rootfs-tar rootfs-ubi rootfs-ubifs
Rebuild the target. Example:
# Tell buildroot to rebuild `rootfs-ubi`
make rootfs-ubi rebuild
If you only want to regenerate the rootfs partition, do
rm -r output/target && make
This helps, e.g., if you removed files in a rootfs overlay.
I'm developing kernel modules right now, and the build times are starting to get under my skin. As a side effect I'm taking way too many "coffee" breaks during builds.
So I was looking for a way to build only the stuffs I need for my platform. Chapter 7 and 8 of "linux kernel in a nutshell" gave a good detail of how to do that by hand. Its a good read : http://www.kroah.com/lkn/
But Although I understand the stuffs, this is still a lot of tweaks to make that work.
2.6.32 and later kernels added a new target make localmodconfig. which scans through lsmod and change the .config appropriately. So I thought I found my "automation". But this perl script has some problem too.
This thread describes the problems : https://bbs.archlinux.org/viewtopic.php?pid=845113
There was also a proposed solution which apparently worked for others , is to run the script directly instead of using make's target.
Although for me, make localmodconfig does not work at all. its because of the following :
make clean
make mrproper
cp /boo/config-'uname -r' .config
make localmodconfig
and it halts with
vboxguest config not found!!
nf_defrag_ipv6 config not found!!
vboxsf config not found!!
vboxvideo config not found!!
The thing is my kernel development environment is inside virtualbox. These vbox modules were installed when I chose to install "virtualbox guest addtion".
And the netfilter module might be a Distribution specific module(Lot of netfilter modules are not part of the mainline kernel, so its not a shock to me), which is not included in mainline kernel.
Now the workaround this obviously unloading these module and trying again. But I'm thinking if there is patch for the streamline_config.pl which will enable the user to exclude certain modules if s/he wants. Problem is I have zero knowledge about perl and I like it that way.
So my problems in nutshell
Patching streamline_config.pl so I can give a list of module name as argument which it will exclude from processing the config file.
The script is located at kernel.org
EDIT: Removed the stuff about perl script not running. As mugen kenichi pointed out (How dumb I can be?). But still make localmodconfig does not work because of not having some modules code under source tree. patching streamline_config.pl still valid requirement.
Anyone else trying to build a minimum kernel image also looking for reducing build time, should do the following:
1) copy distribution kernel config in your source tree. It can be done with either command given below:
$zcat /proc/config.gz > .config
or
$cp /boot/config-'uname -r' .config
2) Use localmodconfig target.
$make localmodconfig
It will use lsmod to find which modules are loaded at this moment. Then it will search through distribution's .config to enable them and disable others.
Its important to know that it does not always work flawlessly. So you should tweak your config further using make menuconfig. You will see some modules are still marked to be built which is in reality unnecessary for your system.
Sometimes out of tree modules may cause make localmodconfig to fail. If that's the case you can work around that issue in two ways :
a) unload the out of tree modules and try make localmodconfig again.
b) Run the perl script directly:
$chmod +x script/kconfig/streamline_config.pl
$perl script/kconfig/streamline_config.pl > .config
3) Install ccache[1]. It will improve your build time dramatically. It caches objects. So it will reduce subsequent builds.
Its possible that ccache is included in the distribution's repository so that you can install it through apt-get or yum. In CentOS its available in EPEL repo.[2]
4) Give as many cores as possible for the build job
$make -j8 CC="ccache gcc"
My results are :
real 3m10.871s
user 4m36.949s
sys 1m52.656s
[1] http://ccache.samba.org/
[2] http://fedoraproject.org/wiki/EPEL