É possível dizer se meu kernel Linux é customizado (isto é, compilado) ao invés de distro?

Question

Tomando exemplo do Ubuntu, podemos dizer se o kernel foi compilado de maneira customizada ao invés do que vem com a distribuição?

    

Answer 1

Claro, basta verificar se dpkg sabe disso.

Primeiro, verifique a versão do kernel que você está executando.

uname -a
Linux orwell 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

Em seguida, informe dpkg para procurar o arquivo de imagem do kernel no banco de dados dpkg .

dpkg -S /boot/vmlinuz-3.2.0-4-amd64
linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64

Ou melhor, use dlocate do pacote dlocate . dlocate primeiro cria um cache do banco de dados dpkg e usa isso. Então é rápido.

dlocate /boot/vmlinuz-3.2.0-4-amd64
linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64

Finalmente, verifique se os arquivos Debian contêm este pacote.

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

Se não, então é um pacote personalizado. É claro que, se o dpkg não souber sobre o arquivo de imagem, então seu kernel não é parte de um pacote, mas foi compilado localmente.

Note que apt pode dizer a diferença entre um pacote no repositório Debian e um compilado localmente com o mesmo nome. Acho que verifica o md5sum do pacote, mas esqueço os detalhes de como isso acontece. Os pacotes binários contêm informações sobre hashes, veja a parte inferior de apt-cache show linux-image-3.2.0-4-amd64 , por exemplo. por exemplo.

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

    

Answer 2

Minimamente, uname -r fornecerá a versão kernal, como 3.18.6 . No entanto, quando o kernel é compilado, uma string adicional pode ser configurada e anexada a ela e as distribuições geralmente fazem isso para indicar seu próprio nível de patch (após um traço) e sabor, como 3.18.6-32-generic . Essa é uma pista; obviamente, usar sua própria string quando você cria um kernel personalizado pode ser outro.

uname -v fornece uma string que, por padrão, é algo assim

#4 SMP PREEMPT Mon Mar 9 13:55:25 EDT 2015

O número é arbitrário no sentido de que é o número de vezes que este kernel foi construído usando uma árvore de origem específica sem a árvore sendo redefinida - isso pode ser útil quando você está construindo o seu próprio. SMP indica um kernel multitarefa (ou seja, não em tempo real) e PREEMPT é outra opção de configuração relacionada ao "modelo de preempção" do agendador. Mas a grande pista aqui é provavelmente a época em que foi construída. Isso pode ser usado para corresponder à modificação / alteração do registro de data e hora no próprio kernel, tendo em mente que isso pode ser alterado, por exemplo, com touch . Por exemplo, stat nesse kernel se parece com isto:

  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: -

O que está praticamente de acordo com Mon Mar 9 13:55:25 EDT 2015 .

    

Answer 3

O mesmo que qualquer outro

sudo apt-cache policy linux-generic

é a versão instalada no gerenciador de pacotes e

uname -r

compare as versões

para mim, é

linux-generic:
  Installed: 3.19.0.15.14
  Candidate: 3.19.0.15.14

e

3.19.0-15-generic

que indicam a mesma versão

    

Answer 4

Eu diria que a resposta mais geralmente verdadeira é "não, você não pode". Existem vários métodos que podem ajudar em certos casos e estes já foram sugeridos, mas todos estes parecem perder como esta situação realmente veio a ser. Na verdade, se você estiver usando um kernel personalizado, esse kernel pode fazer qualquer coisa, incluindo esconder sua presença ou parecer ser um kernel diferente.

Eu ficaria preocupado se você estivesse realmente executando um kernel personalizado e não soubesse disso. A única maneira confiável de saber o que o kernel está sendo usado é cuidadosamente acompanhar quais kernel você compila e instala.

Se você realmente não sabe qual kernel o sistema está rodando ou de que fontes este kernel foi construído ou de onde veio, eu consideraria seriamente reinstalar o SO a partir de uma imagem boa e ser mais cuidadoso no futuro sobre quais kernels você tente inicializar ou usar.