I am trying to compile a Linux kernel version (linux-2.6.32.60) for my Debian machine.
The first step was to create a configuration file (.config) by typing:
make xconfig
Once the configuration file was created, I simply ran make, to build the image kernel and modules. Up to that point no problem.
However, when installing the modules (.ko files), I type:
make modules_install
which instead of installing the newly compiled modules, brings a command line configuration setup, which is incorrect (the configuration file was already created).
Any ideas what is causing the configuration to be restarted?
Regards.
Set the ARCH variable before calling menuconfig
$ make ARCH=arm menuconfig
The issue was caused because of a development environment variable in my O.S setting ARCH to be i386 (that was required for running some infrastructure in our office). Since my kernel runs in a 64-bit processor and xconfig relies on a variable with the same name, the resulting .config file was being generated for a 32-bit architecture, and so was the whole compilation process. In the end, this was causing the installation error (which is indeed expected).
Related
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 using Autotools for my current project. I'm using Ubuntu and Linux mint. With Autotools I can tell it to check a users's system to check for any required libraries my project needs in order to function properly. Now I would like to check if a user's system has enabled core dumps and if not, then execute the command ulimit -c unlimited to enable core dumps. How and where do I specify this?
Also, once the user has executed the make command to compile the source code, they execute sudo make install in order to move the binaries at /usr/local/bin/MYPROJECT. I want to add the location of my project's binaries into the path environmental variable, so that the user can execute any of the binaries in my project from a terminal without the need of typing the full path. How and where do I specify this in Autotools?
I'm thinking this is something I would add in the configure.ac file, but I haven't found any examples on how I can do this. Any help would be appreciated.
It sounds as if you basically misunderstand what installation of a software
package on Linux is about.
The job of autotools is to build a portable installation package of your
software. When I install your package, it does not become your decision
whether programs that crash will generate core dumps on my computer
when I run them. It does not become your decision what PATH I use to
invoke programs by unqualified name. These are my decisions or defaults
that I have accepted from my OS distribution.
If you execute ulimit -c unlimited, the command will in any case
only apply to the shell in which it is invoked. It doesn't
reconfigure the host system (!).
If you would like users to be able to invoke your program by unqualified
name, the normal procedure is make your package install it by default in the place,
/usr/local/bin, that unix-like OSes traditionally add to a
user's default PATH for finding locally installed programs. That is
where autotools will configure it to be installed, by default. Change it
only if you don't want your program to be in the user's default PATH.
And in any case, a user can decide where your software is installed by
passing --prefix=/path/of/my/choice to the ./configure command. Unless
you have some unavoidable reason not to, make your package installation
use the defaults that everybody expects and leave it up to the installing user
to change them.
Bottom line: You are asking how to do installation actions with autotools that
are not meant to be done with autotools, because they are not meant to be
done by package installations.
I'm modifiying the kernel source code (/linux/net/mac80211/mesh_hwmp.c) to add some signature authentication to the routing frames. After modifying the source code, do I have to build and install the kernel again for the changes to take effect?
Following are the steps I followed:
Downloaded the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
After downloading, copied the current config from the / boot directory in wireless-testing $ cp /boot/config- `uname-r` ./.config
Ran make menuconfig and selected the following features:
Networking -> Wireless -> Generic IEEE 802.11 Networking Stack (mac80211)
Built it using fakeroot make-kpkg - initrd kernel_image kernel_headers
After building the kernel, installed the created .deb packages (the core and its headers) using the command
$ sudo dpkg-i linux-*.deb
Did a reboot of the system
It is a time consuming process if I have to undergo this for every change that I make to the code (/net/mac80211/mesh_hwmp.c). I'm not sure if I'm overdoing by building the kernel again. Is it sufficient if I just run the Makefile(s) in mac80211 directory? Or, do I have to go through this process no matter what.
Is the current config from /boot the distro default config? If so, it probably contains hundreds or thousands of modules you will never need. Do that once, install and boot the kernel. Then, make sure you load the modules you're interested in (e.g. enable wifi, plug in USB devices) and run make localmodconfig in your kernel source tree (see make help for details). Enable more configs as needed, and use that for development.
You might also find sudo make INSTALL_MOD_STRIP=1 modules_install install will do the right thing on a lot of distros to install the kernel, and you'll avoid any problems related to creating a package, forcing rebuilds. The downside is you'll have to manually remove the old kernels, configs, initrds from /boot and modules from /lib/modules.
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
I tried using make defconfig to compile the kernel, but as expected, it failed to boot. I was wondering what .config file do kernel vendors like Canonical for Ubuntu use, that the kernel is able to boot right out-of-the-box. Of course, I am still a beginner and configuring the various parameters, is a little out of my league currently.
Specifically,I am looking to load a basic "hello, world!" module to my running kernel 2.6.32.41. For that, I would need to compile kernels source against the same .config file that was used for the running kernel.
If your running kernel was compiled with the CONFIG_IKCONFIG_PROC option, you can get the config in /proc/config.gz:
$ zcat /proc/config.gz >my_config
Copy my_config into your kernel build directory as .config and run make config to be prompted for configuration options that are absent from your config file (this will only happen if you are using a kernel source that is newer than your running kernel). You should then be able to compile a new kernel with the same features as your current one.
Distros typically use their own kernel configuration, where most of the drivers are compiled as modules to be dynamically loaded when the corresponding hardware is requested. Also the kernel needs to be booted with relevant boot options (like the one specifying the root filesystem). Your defconfig kernel probably failed to boot because of that.
I don't know about getting the one that's "correct for your hardware", but you can use the config that Ubuntu gives you by looking in /boot/ for a file starting with the name config. There may be more than one, in which case use the command uname -r to tell which kernel you're currently running, and then you can use the appropriate config.
option1:
source code of your booted system
cd /usr/src/linux-headers-3.2.0-29;
this will generate .config
sudo make oldconfig;
vi .config
option2:
zcat /proc/config.gz > my_config
option3:
echo /boot/config* > my_config
"defconfig" is usually pegged at the commonly used hardware - x86, or x86_64, and perhaps not so recent chipset or motherboard. Sometimes, like my Lenovo laptop, only the latest kernel source, and with enabling some config option, after googling through the bugzilla database, will it work.
Like what Jeff Welling said, to get the config in use, u can look under /boot directory. Same for my Fedora Core too. But if u want to compile a basic program as a "kernel module", and by that it simply means "loadable kernel module", u don't need to compile the kernel source. U just need the kernel headers for that current version. For example, "apt-cache search" in Ubuntu 10.04 returns several possible option:
linux-headers-2.6.38 - Header files related to Linux kernel, specifically,
linux-libc-dev - Linux Kernel Headers for development
Ubuntu normally patched the stock kernel (from kernel.org) to have their own kernel. If u have downloaded the stock kernel, and attempt to use the /boot's config file (or sometimes u can find the currently loaded config as /proc/config.gz, like the Backtrack's Ubuntu, which is based on 10.04 LTS), then u may need to do a "make oldconfig" with the current config file named as ".config". "make oldconfig" will then use the .config to generate a new .config that is compatible with the kernel source.