Ao configurar um sistema contra o seu próprio kernel personalizado, sugiro adicionar um nome à versão atual em suas fontes de kernel modificadas.
Por exemplo, no Armbian eles criam seus próprios pacotes do kernel, e adicionam um -sunxi ao kernel.release.
Como exemplo, modificando a versão do kernel 4.6.3:
root@ruir:/usr/src/linux-headers-4.6.3-sunxi# grep -ri 4.6.3-sunxi *
include/generated/utsrelease.h:#define UTS_RELEASE "4.6.3-sunxi"
include/config/kernel.release:4.6.3-sunxi
e também, para os módulos do kernel, em /lib/modules/4.6.3-sunxi/build :
include/generated/utsrelease.h:#define UTS_RELEASE "4.6.3-sunxi"
include/config/auto.conf.cmd:ifneq "$(KERNELVERSION)" "4.6.3-sunxi"
include/config/kernel.release:4.6.3-sunxi
(consulte instalação sysdig no ARM / Armbian Jessie - módulo compilado na versão do kernel errada )
Como podemos ver, isso pode ser visto em uname -r :
$uname -r
4.6.3-sunxi
Quanto aos pacotes de kernel personalizados:
$dpkg -l | grep sunxi
ii linux-dtb-next-sunxi 5.16 armhf Linux DTB, version 4.6.3-sunxi
ii linux-firmware-image-next-sunxi 5.16 armhf Linux kernel firmware, version 4.6.3-sunxi
ii linux-headers-next-sunxi 5.16 armhf Linux kernel headers for 4.6.3-sunxi on armhf
ii linux-image-next-sunxi 5.16 armhf Linux kernel, version 4.6.3-sunxi
Quanto a adicionar seus próprios cabeçalhos de seu kernel de compilação, vou me referir a KernelHeaders (a ênfase em negrito é minha); se você estiver substituindo versões menores do kernel, você pode (ou não) obter apenas make headers_install .
User space programs
In general, user space programs are built against the header files provided by the distribution, typically from a package named glibc-devel, glibc-kernheaders or linux-libc-dev. These header files are often from an older kernel version, and they cannot safely be replaced without rebuilding glibc as well. In particular, installing /usr/include/linux as a symbolic link to /usr/src/linux/include or /lib/modules/*/build/include/linux is highly discouraged as it frequently breaks rebuilding applications. For instance, older kernels had the architecture specific header files in include/asm-${arch} instead of arch/${arch}/include/asm and had on a symlink to the architecture specific directory.
The correct way to package the header files for a distribution is to run 'make headers_install' from the kernel source directory to install the headers into /usr/include and then rebuild the C library package, with a dependency on the specific version of the just installed kernel headers.
If you are distributing a user space program that depends on a specific version of some kernel headers, e.g. because your program runs only on patched or very recent kernels, you cannot rely on the headers in /usr/include. You also cannot use the header files from /usr/src/linux/include or /lib/modules/*/build/include/ because they have not been prepared for inclusion in user space. The kernel should warn you about this if you try it and point you to this Wiki page. The correct way to address this problem is to isolate the specific interfaces that you need, e.g. a single header file that is patched in a new kernel providing the ioctl numbers for a character device used by your program. In your own program, add a copy of that source file, with a notice that it should be kept in sync with new kernel versions. If your program is not licensed under GPLv2, make sure you have permission from the author of that file to distribute it under the license of your own program. Since your program now depends on kernel interfaces that may not be present in a regular kernel, it's a good idea to add run-time checks that make sure the kernel understands the interface and give a helpful error message if there is no fallback to an older interface.
Também para desenvolvimento de kernel; ou compilando um kernel / módulo para um servidor diferente ou para um kernel diferente com múltiplas versões de kernel instaladas, o SYSSRC pode ser usado para especificar um local de origem de kernel alternativo.