Taking example of Ubuntu, can we tell if the kernel was custom compiled rather than what comes with distro?
Sure, just check whether
dpkg knows about it.
First check the kernel version you are running.
uname -a Linux orwell 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
dpkg to search for the kernel image file in the
dpkg -S /boot/vmlinuz-3.2.0-4-amd64 linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64
Or, better, use
dlocate from the
dlocate first builds a cache from the
dpkg database, and uses that. So it is fast.
dlocate /boot/vmlinuz-3.2.0-4-amd64 linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64
Finally, check that the Debian archives contain this package.
apt-cache policy linux-image-3.2.0-4-amd64 linux-image-3.2.0-4-amd64: Installed: 3.2.68-1+deb7u1 Candidate: 3.2.68-1+deb7u1 Version table: *** 3.2.68-1+deb7u1 0 500 http://security.debian.org/ wheezy/updates/main amd64 Packages 100 /var/lib/dpkg/status 3.2.65-1 0 500 http://httpredir.debian.org/debian/ wheezy/main amd64 Packages
If they don't, then it is a custom package. Of course, if dpkg doesn't know about the image file, then your kernel is not part of a package at all, but has been locally compiled.
apt can tell the difference between a package in the Debian archive and a locally compiled one of the same name. I think it checks the md5sum of the package, but I forget the details of how it does that. The binary packages contain information about hashes, see the bottom of
apt-cache show linux-image-3.2.0-4-amd64, for example. e.g.
Package: linux-image-3.2.0-4-amd64 Source: linux Version: 3.2.68-1+deb7u1 Installed-Size: 105729 [...] Size: 23483788 MD5sum: f9736f30f8b68ae79b2747d8a710ce28 SHA1: 64bfde903892801dccd04b52b12316901a02cd96 SHA256: 775814b3eff4a964b593c0bdeaac20587a4e3ddb1257a9d2bfcf1e9d3b9bfd15
uname -r will give the kernal version, such as
3.18.6. However, when the kernel is compiled, an additional string can be configured in and attached to that and the distros usually do this to indicate their own patch level (after a dash) and flavour, such as
That's one clue; obviously using your own string when you create a custom kernel can be another.
uname -v gives a string which by default is something like this
#4 SMP PREEMPT Mon Mar 9 13:55:25 EDT 2015
The number is arbitrary in the sense that it is the number of times this kernel was built using a specific source tree without the tree being reset -- this might be useful when you are building your own.
SMP indicates a multi-tasking (i.e., not real time) kernel and PREEMPT is another config option related to the scheduler's "preemption model". But the big clue here is probably the time it was built. This could be used to match against the modification/change timestamp on the kernel itself, keeping in mind that can be changed, e.g., with
touch. For example,
stat on that kernel looks like this:
File: ‘3.19-goldilocksSpecial’ Size: 6858880 Blocks: 13400 IO Block: 4096 regular file Device: 801h/2049d Inode: 3156605 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-02-15 15:32:29.000000000 -0500 Modify: 2015-03-03 13:55:21.000000000 -0500 Change: 2015-03-03 14:02:26.767045553 -0500 Birth: -
Which is pretty much in line with
Mon Mar 9 13:55:25 EDT 2015.
Same as any other
sudo apt-cache policy linux-generic
is the version installed though the package manager and
compare the versions
for me its
linux-generic: Installed: 22.214.171.124.14 Candidate: 126.96.36.199.14
which indicate the same version
I would say the most generally true answer is "no, you cant". There are various methods which may help in certain cases and these have been suggested already but these all seem to miss how this situation actually came to be. In truth, if you are using a custom kernel, that kernel can do anything, including hiding its presence or appearing to be a different kernel.
I would be worried if you are indeed running a custom kernel and did not know this. The only reliable way of knowing what kernel is being used is carefully keeping track of which kernel's you compile and install.
If you are genuinely not sure what kernel the system is running or what sources this kernel was built from or where it came from I would seriously consider reinstalling the OS from a known good image and being more careful in future about what kernels you try and boot from or use.