I have downloaded the latest kernel from kernel.org . What I want is to compile it to get the executable file. I need the file to run some commands on it (like strings) to figure what how to identify the linux kernel from its binary file.
All the tutorials on the internet are for upgrading/changing the kernel but I only want the binary file.
I think what you want are vmlinux and *.ko elf files, but you must compile your kernel first. The bzImage is compressed so you cannot run strings on it.
Related
I am planning to run U-boot on an ARM based (Cortex-R5 BIG ENDIAN) embedded system.
U-Boot will run as a second level bootloader on top of a 1st level bootloader
developed using IAR Embedded Workbench for ARM (EWARM).
U-Boot is built on a Linux host computer.
The first level bootloader is developed on a Windows host computer.
I just managed to download the U-Boot ELF file using EWARM but there is no source debugging.
Have not copied the source files, but the ELF file of course contains linux style paths.
Is there any tool that converts an ELF file with linux style paths
to an ELF file with Windows style path?
"objcopy --only-keep-debug foo foo.dbg" takes a full ELF file
and copies just the debug stuff to foo.dbg
objcopy --strip-debug foo then strips the ELF file.
objcopy --add-gnu-debuglink=foo.dbg foo adds the connection to the debug info.
No objcopy option to convert paths as far as I can tell.
Is there any tool which copies a full directory tree, to NTFS handling symbolic links?
Since this is only for source level debug, making duplicates
instead of following the links would be OK.
My best idea is to copy the file system over the network using SAMBA.
Have not tried, but I suspect SAMBA would ignore the links and just make duplicates.
The Windows computer is connected to a company network and the VPN connection
disables all other networks, so I have to use a third computer for this...
Maybe I could SAMBA mount the linux machine on itself....
Ideas appreciated.
Is there any tool which copies a full directory tree, to NTFS handling symbolic links?
You have two options:
Copy the directory to a FAT partition. Symbolic links will be replaced by the actual files. Both Linux and Windows can read and write FAT.
If you are on the same computer: Mount the NTFS partition in Linux. If Windows uses bitlocker you will need the complete key (the PIN is not enough).
What is the easiest way to check just one *.c file from Linux kernel using pvs-studio?
Kernel is a huge project, maybe there is a way to avoid compilation of all files.
If you have compilation parameters of the file in question, you could directly launch the analyzer on this file. Here is an example, and although it's for Windows version (i.e. PVS-Studio.exe), you could do the same under Linux, just replace 'PVS-Studio.exe' with 'PVS-Studio'.
I am trying to compile a kernel module of kernel version 3.2.0 on a linux kernel bzImage loaded on a qemu emulator, however I am getting the following error:
/lib/modules/3.2.0/build no such file or directory. I tried to look up solutions over the net but nothing specific related to solve this for a kernel image being loaded over qemu. The command I issue to load the bzImage on qemu is qemu/qemu-system-x86_64 -m 2G -kernel ../linuxkernel/arch/x86/boot/bzImage -hda ../../sid.ext2 -append "root=/dev/sda"
bzImage only contain kernel's image, it doesn't contain files needed for build modules.
You should:
Find kernel headers(with some files built), corresponded to you kernel, and install them to directory, to which /lib/modules/3.2.0/build points.
Or build kernel from the sources by hands. In that case reference /lib/modules/<kernel-version>/build will point to your compiled source files automatically.
I compiled various Linux kernel from git repositories. There are times when I copied the kernel to other system and need the kernel header to compile external module.
I tried to run "make headers_install" but it only generated a include/ folder. When I tried to point external module to that folder, it complains it cannot find Makefile.
What is the proper way to package kernel-header for deployment?
Thanks.
Create kernel packages instead, that's "make deb-pkg" for dpkg based distros and "make rpm-pkg" for RPM based ones. These create multiple packages, one of those is a package usable for external modules building. That should be linux-headers-* for the Debian packages and a "devel" package for he RPM versions.
In some ways this is just an expansion of the previous answer. If you look at the file scripts/package/builddeb in the kernel sources you will find script code which selects the files needed for building external modules from a kernel build and puts them into /usr/src/linux-headers-$version. I can find that script code in my local kernel version by searching for the string "# Build kernel header package" in the builddeb file. If you want to do things by hand you could execute that script code manually.
I have compiled my kernel(linux-3.6.6) with success in the debian linux version(12.04).(LinuxPraxis ->is the name of my new version) then I made some modification on Read_write.c file ("I mind I write there some printk to get a message when a named pipe is writting and when it is reading").
Now I hear that I need to recompile my new version. please help me to understand it.
Shall I need to recompile my kernel completely or it is another way to recompile a kernel?
Use "make -j5" to rebuild your kernel image file for host system with 4 cores.
Then run "make install -j5" to install kernel image file.
The "make install" will compress your kernel image file, copy kernel image to /boot and run grub-update to update the grub config file.
If you have already compiled, the Makefile takes care of only recompiling the parts which depend on the changed file(s). There could still be multiple files which depend on it, but the effort should be significantly smaller than the initial compilation nevertheless. You don't have to do anything differently, the compilation works the same; files which already exist on disk which do not depend on the changed file will simply not be recompiled.