CentOS 6.5 compiling kernel source seeing "LINUX_VERSION_CODE" unset - linux

I followed following instructions to install the kernel source code onto my CentOS 6.5 development box(from http://wiki.centos.org/HowTos/I_need_the_Kernel_Source)
[user#host]$ cd ~/rpmbuild/SPECS
[user#host SPECS]$ rpmbuild -bp --target=$(uname -m) kernel.spec
Overall, I now have the source under ~/rpmbuild/BUILD/kernel-2.6.32-431.20.3.el6/linux-2.6.32-431.20.3.el6.x86_64/
However, when I try to compile netmap (which applies patches to the kernel source directory). I notice the following warnings
ERROR: Kernel configuration is invalid.
include/linux/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.
I am not seeing this on Ubuntu. I'm suspecting that I did not prepare the kernel source tree correctly, can I do that with Redhat kernel source RPM?

Ran, "make oldconfig", "make preprare", and "make prepare scripts" prior to building against kernel source

Related

Linux kernel compile error

I cloned the kernel sources from Linus's github, I made a little modification to the usbhid driver (thats compiles fine as a module, no errors), but if I try to build the whole kernel, I get this error:
AR drivers/gpu/drm/built-in.o
AR drivers/gpu/built-in.o
Makefile:1023: recipe for target 'drivers' failed
make: *** [drivers] Error 2
And thats all nothing specific. What could be the problem?
UPDATE: 9-15-18 This issue is resolved.. The kernel will now compile with the commands I have given below.
Same issue here. 4.19.0-rc3 will not compile on the Threadripper 2990WX. BTW, I am currently running 4.19.0-rc2 with no issues.
These are the commands I used. Please note, I also tried without the LD static flag.
wget https://git.kernel.org/torvalds/t/linux-4.19-rc3.tar.gz && tar -xzf linux-4.19-rc3.tar.gz && cd linux-4.19-rc3 && make -j 64 clean && make -j 64 mrproper && zcat /proc/config.gz >> ./.config && LDFLAGS=--static make -j 64
The issue is in your config file. I have faced the same issue before and and appears to be due to a missing CONFIG option in the .config file generated through make menuconfig.
You need to add these two CONFIG options in your .config file:
CONFIG_EXTRA_FIRMWARE_DIR="lib/firmware"
CONFIG_EXTRA_FIRMWARE="<name_of_firmware_along_with_path>"
In some platforms, the GPU uses firmware that needs to be built-in by stitching it with kernel. This firmware is placed in the directory path provided by CONFIG_EXTRA_FIRMWARE option while building the kernel. And unless we don't provide CONFIG_EXTRA_FIRMWARE_DIR path to tell the kernel where to pick this firmware from, the above build failure occurs.

Linux Kernel makefile process explained

In LinuxSrc/Documentation/admin-guide/README.rst under the section for building the kernel exists these 4 steps, can someone explain what each one does?
Is it similiar to a ./configure, ./make, ./install?
To configure and build the kernel, use:
1.) cd /usr/src/linux-4.X
2.) make O=/home/name/build/kernel menuconfig
3.) make O=/home/name/build/kernel
4.) sudo make O=/home/name/build/kernel modules_install install
1) simple cd - no explanation needed
2) Running make menuconfig starts an ncurses-based text mode kernel configuration tool.
3) make O=/home/name/build/kernel configures and builds the kernel.
4.1) modules_install: This will copy the compiled modules into /lib/modules/-.
4.2) install: This command will copy following files into /boot directory (and might do more depending on the distribution):
Config-, System.map-, Vmlinuz-*
vmlinuz - Is a compressed Linux kernel
system.map - Is a lookup table between symbol names and their addresses in memory for a particular build of a kernel
config - The kernel configuration created by the make menuconfig

The Jungo WinDriver need a linux symbolic link , what does it mean?

Its manual says:
To run GUI WinDriver applications (e.g., DriverWizard [5]; Debug Monitor [7.2]) you must also
have version 5.0 of the libstdc++ library — libstdc++.so.5. If you do not have this file, install it from the relevant RPM in your Linux distribution (e.g., compat-libstdc++).
Before proceeding with the installation, you must also make sure that you have a linux symbolic link. If you do not, create one by typing : /usr/src$ ln -s 'target kernel'/linux
For example, for the Linux 2.4 kernel type :
/usr/src$ ln -s linux-2.4/ linux
what does this symbolic link mean ? what do the <target kernel> and linux preset ?
If I install WinDriver in Ubuntu 13.10 , how should specify these two parameters ?
When installing WinDriver on a Linux machine, you must make sure that you are compiling WinDriver with the same header files that were used to build your kernel. #uname -a will tell you your kernel version number.
You should verify that the directory /usr/src/linux (normally a symbolic ink) is pointing to the correct kernel header sources and that the header files are using exactly the same version numbers as your running kernel.
A refers to the location of the kernel headers and refers to the Linux kernel name-number.
To fix this:
Become super user: $su ;
Change directory to: /usr/src/: # cd /usr/src/ ;
Delete the previous link you created (if any): # rm linux ;
And create a new symbolic: # ln -s linux-2.4/ linux.
I recommend following the Linux installation procedure from the Windriver manual at:
http://www.jungo.com/st/support/documentation/windriver/11.5.0/wdpci_manual.mhtml/wd_install_process.html#wd_install_linux
Regards,
Nadav, Jungo support manager

building /lib/modules/$(uname -r)/build while compiling a kernel

I am cross-compiling 3.4.0 kernel for an embedded device. Then I would like to install compat-wireless drivers which require /lib/modules/3.4/build directory and sub-files. Could anyone explain how can I build that directory so that when I do INSTALL_MOD_PATH=newmodules make modules_install it would load /lib/modules/$(uname -r)/build directory as well? I would appreciate for a clear explanation.
I am using debian distro. I know I can install the kernel headers by apt-get install linux-headers-$(uname -r), but I doubt it would be a good idea since the kernel sources might not be identical.
Typically /lib/modules/$(uname -r)/build is a soft-link to the directory where performed the build. So the way to do this is to simply do a
make modules_install INSTALL_MOD_PATH=/some/root/
in the build directory of the kernel where /some/root is where you want your cross compile pieces to end up. This will create a link to your kernel build path in /some/root/lib/modules/$(uname -r) ... verify that.
Now when you build the compat_wireless drivers specify the kernel build directory in the Makefile as /some/root using the KLIB_BUILD variable (read the Makefile)
make modules KLIB_BUILD=/some/root/lib/modules/$(uname -r)/build
this should do the trick for you.
EDIT A
In answer to your comment below:
Keep "newmodules" outside the kernel directory it's a bad idea to put it in the kernel directory. so mkdir newmodules somewhere like /home/foo or /tmp or something. This is one of the reasons your build link is screwed up
ALSO .../build is a soft link /to/kernel/build/location it will only copy over as a soft-link. You also need to copy over the actual kernel source / kernel build directory to your microSD, using the same relative location. For example,
Let's say your kernel source is in:
/usr/src/linux-3.5.0/
Your kernel build directory is:
/usr/src/linux-3.5.0-build/
Your newmodules (after following 1.) is in:
/tmp/newmodules/
So under /tmp/newmodules/ you see the modules installed in a tree like:
lib/modules/$(uname -r)/
when you do an ls -al in this directory, you'll see that build is a soft link to:
build -> /usr/src/linux-3.5.0-build/
Now let's say your microSD is mounted under /mnt/microSD
then you need to do the following
mkdir -p /mnt/microSD/usr/src
cp -a /usr/src/linux-3.5.0 /usr/src/linux-3.5.0-build /mnt/microSD/usr/src
cp -a /tmp/newmodules/lib /mnt/microSD/lib
Now you have all the content you need to bring over to your embedded environment. I take it you are doing the compat_wireless build on your target system rather than cross compiling it?
NOTE
If your kernel build is the same as the kernel source then just copy over the kernel source and ignore the linux-3.5.0-build in copy instructions above
This is old, but some people will need this information.
I have spent many hours to figure out where build folder comes from, and why it is just a link when I compile my own kernel. Finally figured it out;
Linux kernel usually just links the build and source folders to the source folder.
But!
Arch linux (probably some other distros too); has a manual script for deleting those links, and adding (filtered) files to build folder.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
I've extracted that script to work standalone (in a kernel source tree) here: https://gist.github.com/furkanmustafa/9e73feb64b0b18942047fd7b7e2fd53e

How to debug my Cross compiled Linux Kernel?

I 've cross compiled a Linux Kernel (for ARM on i686 - using Cross-LFS).
Now I'm trying to boot this Kernel using QEMU.
$ qemu-system-arm -m 128 -kernel /mnt/clfs-dec4/boot/clfskernel-2.6.38.2 --nographic -M versatilepb
Then, it shows this line and waits for infinite time !!
Uncompressing Linux... done, booting the kernel.
So, I want to debug the kernel, so that I can study what exactly is happening.
I'm new to these kernel builds, Can someone please help me to debug my custom built kernel as it is not even showing anything after that statement. Is there any possibility of the kernel being broken? ( I dont think so, b'se it didnot give any error while compiling )
And my aim is to generate a custom build very minimal Linux OS. Any suggestions regarding any tool-chains etc which would be easy & flexible depending on my requirements like drivers etc.,
ThankYou
You can use GDB to debug your kernel with QEMU you can use -s -S options. If you want a simple and reliable toolchain, you can use ELDK from DENX (http://www.denx.de/wiki/DULG/ELDK).
You can install it like this (It's not the last version, but you got the idea):
wget http://ftp.denx.de/pub/eldk/4.2/arm-linux-x86/iso/arm-2008-11-24.iso
sudo mkdir -p /mnt/cdrom (if necessary)
sudo mount -o loop arm-2008-11-24.iso /mnt/cdrom
/mnt/cdrom/install -d $HOME/EMBEDDED_TOOLS/ELDK/
The command above should install the toolchain under $HOLE/EMBEDDED_TOOLS/ELDK (modify it if you need)
echo "export PATH=$PATH:$HOME/EMBEDDED_TOOLS/ELDK/ELDK42/usr/bin" >> $HOME/.bashrc
You can then see the version of your ARM toolchain like this:
arm-linux-gcc -v
You can test a hello_world.c program like this:
arm-linux-gcc hello_world.c -o hello_world
And you type: file hello_wrold to see the target architecture of the binary, it should be something like this:
hello_wrold: ELF 32-bit LSB executable, ARM, version 1 (SYSV)
Now if you want to compile a production kernel, you need to optimize it (i suggest using busybox) and if you want just one for testing now, try this steps:
Create a script to set your chain tool set_toolchain.sh:
#! /usr/bin/sh
PATH=$PATH:$HOME/EMBEDDED_TOOLS/ELDK/ELDK42/usr/bin
ARCH=arm
CROSS_COMPILE=arm-linux-gnueabi-
export PATH ARCH CROSS_COMPILE
And run your script (source ./set_toolchain.sh)
Download a linux kernel and unzip it (Let's assume 2.6.x, it's an old kernel, but there are a lot of chances that it work without compilation errors).
Inside your unzipped kernel:
cd ~/linux-2.6.29/arch/arm/configs
make versatile_defconfig
Here we use versatile chip, you may need to use make menuconfig to modify the option OABI and set it to ARM EABI, this option is under Kernel features menu
After all this steps, you can compile you kernel:
make
if you want verbose compilation make v=1
After this you got your kernel under arch/arm/boot/zImage.
Hope this help.
Regards.
I would suggest to build your kernel by activating the option in the section Kernel hacking of your configuration file.
Then you may use kdb or kgdb which is easier to use but requires another machine running gdb.
`
You can also connect Qemu and GDB. Qemu has the -s and -S options that run a GDB server and allow you to connect to it via TCP to localhost:1234. Then you can load your kernel image (the unzipped one) in GDB and see how far your kernel boots.

Resources