Linux find kernel file

Linux – find the Linux kernel file

There no universal standard, but the kernel is usually found in the /boot directory.

Related Solutions

Linux – find linux-kernel-headers-x.x.x.x for SUSE

The kernel-header error is misleading — you have to install kernel-source. (After you do that, you might have to update the kernel itself, so check that afterwards.)

Linux – How to a linux kernel be so small

Yes. If you strip them down (compile/make modules only things that you need), compress the kernel (optimize for size). it’ll result in such a small kernel. You can make an even smaller ones, for targeted system. Like I know my PC, I know my stuff. So I’ll just compile what I need. Like my own SATA drivers, driver for USB, etc. Nothing else. No webcam, no old IDE drives, nothing.

Also: The bigger ones you encounter are the WHOLE kernel (which one never needs to use). Even the desktop ones contains (most of the times, as modules) a LOT OF unneeded stuff. But newbies expect that every kind of hardware they plug-in will just work.

(Note that, the modules won’t get loaded until they are needed. There are 3 states:
[ ] — Won’t get compiled, won’t be part of your kernel.
[M] — Will be compiled as a module.
(You can modprobe it, or your system will auto-load it when it’s needed.
Depends on the system, userland.)
[X] — It’ll be compiled into the kernel AND will be present — always.

Distros with small kernel:

Related Question

Источник

Where exactly is the file linux/kernel.h?

I am reading through Salzman’s Linux Kernel Module Programming Guide, and I was wondering about where the file linux/kernel.h is located. I couldn’t find it with find . Or rather the files I found did not have any printk priority macros in them.

3 Answers 3

The linux/kernel.h header which gets used for module builds is the header which is part of the kernel source. When modules are built in the kernel source tree, that’s the version which is used.

For external module builds, the build process looks for the header in /lib/modules/$(uname -r)/build/include/linux/sched.h . That file is provided by kernel header packages, e.g. on Debian derivatives, the linux-headers-$(uname -r) package.

The /usr/include/linux/kernel.h is intended for user processes, not for kernel modules.

The printk priority macros now live in linux/printk.h and linux/kern_levels.h . I’m guessing you’re reading the original guide, which is based on the 2.6 kernel series; for modern kernels you should read the updated guide (currently for 5.6.7).

On my Mint 18.x system with the build-essential BUT not any full source tree installed —

user@localhost:~ $ locate kernel.h | grep \/kernel.h$ /usr/include/linux/kernel.h /usr/src/linux-headers-4.4.0-21/include/linux/kernel.h /usr/src/linux-headers-4.4.0-21/include/uapi/linux/kernel.h /usr/src/linux-headers-4.4.0-21-generic/include/config/debug/kernel.h /usr/src/linux-headers-4.4.0-21-generic/include/config/firmware/in/kernel.h /usr/src/linux-headers-4.4.0-53/include/linux/kernel.h /usr/src/linux-headers-4.4.0-53/include/uapi/linux/kernel.h /usr/src/linux-headers-4.4.0-53-generic/include/config/debug/kernel.h /usr/src/linux-headers-4.4.0-53-generic/include/config/firmware/in/kernel.h /usr/src/linux-headers-4.8.0-53/include/linux/kernel.h /usr/src/linux-headers-4.8.0-53/include/uapi/linux/kernel.h /usr/src/linux-headers-4.8.0-53-generic/include/config/debug/kernel.h /usr/src/linux-headers-4.8.0-53-generic/include/config/firmware/in/kernel.h 

Per Jeff’s comment on your question, I would assume that most times /usr/include/linux/kernel.h is what will be used,

I’m sure if you extract a kernel tree tarball it may have another copy in its directory structure as well. A quick check shows them all as being different sizes. or empty files.

Источник

Where can I find the kernel configuration on each Linux distribution?

I’m pretty sure that all Red Hat and Debian based distributions follow the convention of shipping the kernel configuration in /boot/config-* , but what of other distributions? Or, if this convention is extremely common, which distributions don’t follow it?

This, I think, is a which distribution. question which does not rely on opinion for answer. Kind of a breath of fresh air — there aren’t too many of those. Also, it’s interesting. Thanks.

@mikeserv too broad might fit, though. 😛 On-topic: I think Arch Linux doesn’t. But I don’t have a installation handy to check.

@muru — arch here: ls: cannot access /boot/config*: No such file or directory . But, then again, an archer’s /boot is a very personal thing. On the other hand, ls /proc/config.gz is entirely successful.

2 Answers 2

Debian and derivatives (Ubuntu, Linux Mint, …)

The configuration for the kernel /boot/vmlinuz-VERSION is stored in /boot/config-VERSION . The two files ship in the same package, linux-VERSION or kernel-VERSION .

Arch Linux, Gentoo (if enabled)

The configuration for the running kernel is stored in the kernel binary and can be retrieved with zcat /proc/config.gz .

This file exists when the CONFIG_IKCONFIG option is set when compiling the kernel — and so can be true (or not) regardless of distribution, though the default kernel configuration for the two named does enable it.

Incidentally, arch linux’s default configuration does not name the kernel (or its initramfs image) by version even in /boot — the files there are named only for their corresponding packages. For example, a typical arch linux boot kernel is named /boot/vmlinuz-linux where linux is the package one installs for the default kernel.

The linux kernel source comes with an installation mechanism, make install . This installs files into /boot (vmlinuz-version, System.map-version, and config-version).

The option to make the running kernel’s config available via /proc/config.gz is part of the kernel too, so if this config option has been enabled the file will exist in the /proc filesystem. Almost all distributions have this enabled these days, even Android kernels, and as such, this is the most standard location.

Neither of these locations is dependent on the distribution though. Many distributions take advantage of the ‘default’ location when packaging, as it’s probably convenient to prepare packages this way, but even within a single distribution it’s possible that non-standard kernel packages might place the files elsewhere, or name them differently, although this is unlikely.

Источник

kernel source code location in linux

I am working in Windows and running fedora through VMware. By default, the kernel source tree should be in usr/src/ directory. Instead I could find only an empty directory called kernels. The actual source code is missing there. When browsing I thought it might be in other directories like /boot . But I couldn’t find source tree there as well. I need to modify system call tables for which I should be able to access those source codes.

3 Answers 3

Kernel source is not installed by default. You can follow e.g. the instructions here to install the source and build your kernel.

You probably need to install the kernel-devel package.

On Fedora, all of the software is managed through a system called the Red Hat Package Manager (RPM). Every file (other than user data and other transient files like logs and such) is «owned» by a package. The ls command is from coreutils , the kernel is probably from kernel and BZFlag (the greatest Linux game ever) is provided by the bzflag package.

In the good old days, you would try to install software by using the rpm command (type » man rpm » for more information) and giving it the path to an RPM file that you had downloaded. The rpm command would then dutifully respond by informing you that you first need to satisfy 33 prerequisites. Then you would go download those 33 prerequisites and try to install them, only to find that each of those had their own prerequisites. And so on.

These days, Fedora has a nice set of online repositories of packages (and you can add others for third party software), and a program called yum that can download databases of all the packages, and you tell yum «install package foo for me» (by typing something like » yum install kernel-devel «) and it goes and figures out that in order to install that package, you need a bunch of other prerequisite packages, and so on. It then automatically downloads and installs everything you need, and away you go. For more information on the various incantations that make yum go, see » man yum «).

Источник

Once booted, Find Full Path of Kernel Image?

I know you can deduce which kernel image is currently running by checking /proc/cmdline and assume its the same one on the /boot mount point. But this isn’t guaranteed. So is there a way to know what image off of what partition with certainty? Is the image file available for inspection by initramfs at a well-known path?

1 Answer 1

Getting the kernel image to the system RAM is the bootloader’s job; only the bootloader knows for certain where the kernel image came from. If the system is booted from network, the kernel image might not be present as a file on the system at all.

The version number and compilation timestamp reported by uname -a might be helpful in identifying the kernel image file. The same information can be read from a kernel image file by using the file command:

$ uname -a Linux hostname 4.9.80-atom #1 SMP Mon Feb 5 13:26:54 EET 2018 x86_64 GNU/Linux $ file /boot/vmlinuz-4.9.80-atom /boot/vmlinuz-4.9.80-atom: Linux kernel x86 boot executable bzImage, version 4.9.80-atom (user@hostname) #1 SMP Mon Feb 5 13:26:54 EET 2018, RO-rootFS, swap_dev 0x3, Normal VGA 

On UEFI systems, you can view the UEFI boot variable BootCurrent to see which of the NVRAM boot options was chosen. But this is not very strong proof, as the boot option may have been edited after the boot happened, and if it points to a bootloader which can offer multiple boot options, it’ll be ambiguous anyway.

The only strong proof I know of would be using a system with a TPM chip and a TPM-aware bootloader: it will store a cryptographically strong hash of the kernel originally loaded into the appropriate PCR register of the TPM. You would then be able to follow the same rules, recalculate the hash and see if it matches; if not, someone has tampered with either the kernel or the PCR register value. And the firmware will always fill another PCR register with a hash of the boot code actually used, so you can see any tampering of the bootloader too.

(The PCR registers are implemented in such a way that you cannot just set them into a value of your choosing: the new value will always be a cryptographically strong hash of the old value + any new data entered, so setting a PCR register to a specific known value when it already has some other non-zero value will be extremely hard.)

Источник