Error ao Compilar o Kernel 4.5

welissonmoura · 23 de Março de 2016, 22:15

Pessoal! estou tentando compilar o kernel 4.5 para o ubuntu 14;04LTS para arquitetura amd64 Athlon64 seguindo o tutorial abaixo:
http://blacksungod.blogspot.com.br/2015/07/ubuntu-compilando-instalando-o-kernel.html
Infelizmente um mensagem de erro é exibida:

"

make -f debian/rules debian/stamp/conf/kernel-conf
make[1]: Entering directory `/usr/src/linux-4.5'
====== making target debian/stamp/conf/kernel-conf [new prereqs: ]======
make ARCH=x86_64 \
oldconfig;
make[2]: Entering directory `/usr/src/linux-4.5'
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
make[2]: Leaving directory `/usr/src/linux-4.5'
make ARCH=x86_64 prepare
make[2]: Entering directory `/usr/src/linux-4.5'
Makefile:666: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
scripts/kconfig/conf --silentoldconfig Kconfig
make[2]: Leaving directory `/usr/src/linux-4.5'
make[2]: Entering directory `/usr/src/linux-4.5'
Makefile:666: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CC kernel/bounds.s
gcc: error: unrecognized command line option '-fstack-protector-strong'
make[3]: *** [kernel/bounds.s] Error 1
make[2]: *** [prepare0] Error 2
make[2]: Leaving directory `/usr/src/linux-4.5'
make[1]: *** [debian/stamp/conf/kernel-conf] Error 2
make[1]: Leaving directory `/usr/src/linux-4.5'
make: *** [debian/stamp/conf/minimal_debian] Error 2
Failed to create a ./debian directory: at /usr/bin/make-kpkg line 984.

"

Alguém poderia me dar uma luz?

platao · 23 de Março de 2016, 23:18

O ubuntu 14.04 usa por padrao o GCC 4.8, a partir da versao 4.9 do gcc ocorreram algumas modificaçoes que eu nao sei ao certo, mas parecem ser entre outras de segurança, o problema e que esta gerando erros na compilação.

Entao para que vc consiga compilar o kernel 4.2 e 4.3 e mais recentes no ubuntu 14.04 vc precisa proceder dessa forma;

sudo gcc --version

veja a versao do seu gcc;

provavelmente 4.8 vamos atualizar;

sudo apt-get install build-essential

sudo add-apt-repository ppa:ubuntu-toolchain-r/test

sudo apt-get update

sudo apt-get install gcc-4.9 g++-4.9 cpp-4.9

Ou somente de um;

sudo apt-get upgrade

ai tente novamente a compilação.

Talvez se ele ainda acusar erro Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler o mesmo erro, se o PPA nao atualizar o GCC para vc, talvez seja necessario linkar o novo manualmente dai e so proceder;

sudo rm /usr/bin/cpp /usr/bin/gcc /usr/bin/g++ ---->apaga o velho

sudo ln -s /usr/bin/cpp-4.9 /usr/bin/cpp ---->coloca a 4.9 ou superior, versao nova aqui
sudo ln -s /usr/bin/gcc-4.9 /usr/bin/gcc
sudo ln -s /usr/bin/g++-4.9 /usr/bin/g++

ai tente novamente a compilação!

welissonmoura · 24 de Março de 2016, 10:00

Bom, esse erro foi corrigido. Entretanto, ocorreu outro erro envolvendo a lib openssl. Instalei a lib mas ainda os erros persistem.

"

====== making target debian/stamp/build/kernel [new prereqs: vars]======
This is kernel package version 12.036+nmu3.
restore_upstream_debianization
test ! -f scripts/package/builddeb.kpkg-dist ||   mv -f scripts/package/builddeb.kpkg-dist scripts/package/builddeb
test ! -f scripts/package/Makefile.kpkg-dist ||   mv -f scripts/package/Makefile.kpkg-dist scripts/package/Makefile
/usr/bin/make -j4 ARCH=x86_64 \
           bzImage
make[1]: Entering directory `/usr/src/linux-4.5'
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
EXTRACT_CERTS certs/signing_key.pem
At main.c:154:
- SSL error:0906D06C:PEM routines:PEM_read_bio:no start line: pem_lib.c:703
extract-cert: certs/signing_key.pem: Success
rm: cannot remove 'certs/signing_key.x509': No such file or directory
make[2]: *** [certs/signing_key.x509] Error 1
make[1]: *** [certs] Error 2
make[1]: *** Waiting for unfinished jobs....
CHK include/generated/compile.h
make[1]: Leaving directory `/usr/src/linux-4.5'
make: *** [debian/stamp/build/kernel] Error 2

[/i]"

platao · 24 de Março de 2016, 16:08

VC quer compilar o kernel ou vc somente quer usar o kernel 4.4? Se vc quiser usar o kernel do ubuntu 16.04 e so instalar o pacote pelo synaptic o linux-lowlatency-lts-xenial e pronto!

Se quiser o kernel pronto pede pegar aqui por exemplo http://kernel.ubuntu.com/~kernel-ppa/mainline/ vc tbm pode testar o kernel low latency....o kernel Daily que e o mais atual possivel ou entao o kernel padrao mesmo.

Se vc quiser compilar na unha vai ter que preparar com dependencias a sua maquina e ir solucionando e pesquisando os erros que vai dar.

Se quiser compilar vc tbm pode dar o comando sudo apt-get build-dep linux-lts-xenial que o sistema vai instalar nao todas mas muitas das dependencias necessarias, tem um topico aqui no forum sobre kernel http://ubuntuforum-br.org/index.php/topic,29799.0.html quanto ao erro apresentado parece ser erro de certificado...

welissonmoura · 24 de Março de 2016, 16:43

Desejo compilar o kernel por dois motivos, a minha máquina é um pouco antiga e por isso estou tendo alguns problemas de compatibilidade com os kernels atuais, e não gostaria de instalar um kernel antigo. O segundo motivo é que desejo compilar o kernel para a arquitetura específica do meu processado,uma em vez que, a arquitetura genérica disponibilizada no repositório do linux.

welissonmoura · 24 de Março de 2016, 17:08

Consegui resolver o problema de certificado e consegui compilar o kernel.
Procedimento adotado:

-instalação do gcc, g++ e cpp versão 5.0 e remoção do anterior (4.

, pelos comandos:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-5 g++-5 cpp-5
sudo rm /usr/bin/cpp /usr/bin/gcc /usr/bin/g++
sudo ln -s /usr/bin/cpp-5 /usr/bin/cpp
sudo ln -s /usr/bin/gcc-5 /usr/bin/gcc
sudo ln -s /usr/bin/g++-5 /usr/bin/g++
sudo apt-get install build-essential
sudo apt-get upgrade

- reiniciei o sistema
- Correção do problema de certificado:
percebi que o arquivo /usr/src/linux/certs/x509.genkey estava em branco. Para corrigilo, preenchi com o código abaixo:

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts

[ req_distinguished_name ]
CN = Modules

[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid

segundo tutorial : https://wiki.gentoo.org/wiki/Signed_kernel_module_support
Em seguida utilizei o seguinte comando para marcar as opções necessárias no arquivo .config

sudo make menuconfig

no menuconfig em Module signature verification as seguintes opões foram marcadas:

--- Enable loadable module support

Module signature verification
Require modules to be validly signed
Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->[/font]

salvei as configurações e em seguida executei os seguintes comandos:
sudo make-kpkg clean

em seguida executei o comando para compilar o kernel:
sudo make-kpkg --initrd -j 4 kernel_image kernel_headers

no fim da compilação para instalar o kernel recem compilado, utilizei o comando:
cd ..
sudo dpkg -i *.deb

O kernel foi compilado, porém ao instalá-lo e reiniciar o sistema o mesmo não iniciou e os módulos não foram levantados.

Alguma sugestão?

platao · 25 de Março de 2016, 04:21

Vc colocou seu novo kernel para iniciar no grub?

galactus · 25 de Março de 2016, 09:17

Platão, como ele criou o arquivo .deb do kernel compilado, pelo que pude entender, ele já criou seu init no Grub. Por isso ele pôde escolher este outro kernel na inicialização do Grub.

Vários motivos podem fazer este novo kernel não subir, os mais simples:

1) É mais fácil ele não subir por você ter retirado módulos demais durante o menuconfig. Foi isso o que você fez?

2) Este kernel pode não ser compatível com seu hardware. Neste caso fica fácil descobrir, você pode fazer como o Platão sugeriu, baixe um kernel 4.5 já compilado do Ubuntu e testa aí! Se nem o kernel já compilado do Ubuntu subir, este kernel tem sérios problemas de compatibilidade com sua máquina. Por exemplo, muitos drivers de vídeos deixam de funcionar com mudança de kernel. Você vai ter que procurar outra versão.

3) Se você instalou um driver de vídeo proprietário e trocou de kernel, pode precisar de outras duas coisas para ele funcionar. Pode ser necessário reinstalar o driver proprietário ou usar o dkms para ele recriar os módulos do driver de vídeo para o novo kernel durante a instalação do mesmo.

Agora algumas outras explicações pois noto que estão ocorrendo algumas interpretações incorretas:

a) A questão da arquitetura e o nome do kernel generic

Você compila o kernel para arquitetura 32 ou 64 bits. Ponto. O nome generic não tem haver com a arquitetura do kernel e sim com a configuração do kernel para ser o mais compatível possível com qualquer tipo de hardware disponível e uso do sistema. Como o desenvolvedor não sabe em qual hardware o kernel vai funcionar e nem em que situação você vai fazer uso do sistema, ele tenta usar uma configuração que vai funcionar bem em todos os casos. Mas vai pecar pela falta de ajuste fino, como ter apenas os módulos que vão funcionar no seu hardware, isso vai diminuir consideravelmente o tamanho do kernel. Mas você pode fazer isso pelo menuconfig. Ou configurar a parte do processador e memórias para máximo desempenho. Por isso você compila o kernel, para fazer este ajustes finos que numa configuração genérica não é possível.

O kernel low-latency, por exemplo, foi configurado para seus sistema responder o mais rápido possível. Ma nem sempre isso é bom, dependendo do que você vai fazer com seus sistema e da potência do seu processador e quantidade de RAM. Já um kernel para servidor não será nunca o mais rápido a te dar resposta, mas com certeza ele não deve pedir água quando muito exigido e deve priorizar estabilidade.

b) Nem sempre usar um kernel mais novo, seja em hardware antigo ou não, é a melhor opção!

Este é outro erro bastante comum. A cada nova versão do kernel novos drivers são incluídos e velhos retirados, correções de bugs são feitas nas mais diversas áreas e novas tecnologias podem ser colocadas para teste! Então muitas vezes essas coisas novas podem trazer mais problemas do que soluções! E em se tratando de hardware antigo isso pode piorar muito.

Por exemplo, você está sabendo que o desde o kernel 4.2 muitos usuários estão tendo queda de rendimento com processadores Intel modernos? Isso vem afetando as versões 4.2, 4.3, 4.4 e 4.5. Só na versão 4.6 é que vão incluir um patch para corrigir o problema! Eu mesmo tive problemas sérios com a versão 4.2, só na 4.3 tudo voltou ao normal nas minhas máquinas. Na versão 4.4 foi o suspender para RAM que deixou de funcionar! E assim vai, não é por ser mais novo que é melhor. Para o hardware do meu Notebook a versão 4.3 está melhor.

Você não falou sobre o hardware antigo que você tem aí, mas dependendo do quão antigo seja ele, talvez um kernel mais antigo seja a melhor opção. Só testando aí pra saber!

Agora algumas dicas:

1) Você pode usar o comando make localmodconfig para copiar apenas a configuração dos módulos em uso em seu sistema para o novo kernel! Já te aviso logo que isso é uma faca de dois gumes. Por um lado é uma mão na roda. Você vai ter um kernel enxuto, apenas com o que você usa. Mas se trocar de harware, ele pode não subir ou não funcionar. Como uma vez eu retirei todos os módulos de placa de rede wifi, pois era um PC com internet cabeada e depois eu comprei uma placa de rede wifi pci. Não entendia no começo o motivo dela não funcionar, já que sabia de sua compatibilidade com Linux. Daí lembrei que o kernel que eu usava não tinha os módulos para wifi! Resultado? Nova compilação!

O make localmodconfig deve ser usado antes do make menuconfig. Aí você pode dar uma refinada melhor se quiser com o make menuconfig.

2) Usar o método antigo de compilação é ótimo para o aprendizado e ganhar conhecimento, mas você pode tentar também o kernel utilities:
https://github.com/mtompkins/linux-kernel-utilities

3) Só para atualizar algumas coisas. Agora o novo comando seria make nconfig no lugar do make menuconfig. Mas não tem problema em ficar com o make menuconfig. E você pode usar o novo comando make deb-pkg ao invés do make-kpkg.

Como você pode notar, não vão faltar emoções querendo mexer no que há de mais novo!
Passou o cartão? Espero ter ajudado mais que prejudicado.

zekkerj · 01 de Abril de 2016, 17:26

Desculpem o mau jeito da pergunta, mas... alguém já parou pra medir/comparar o tempo gasto com essas otimizações do kernel, com o ganho de desempenho, pra saber quanto tempo se leva pra recuperar o investimento?

Pq, tipo, se vc leva uma semana pra fazer uma compilação customizada de kernel, mas ganha 1 minuto por dia, de aceleração, quanto tempo vai levar pra recuperar o tempo investido nessa compilação?

galactus · 01 de Abril de 2016, 18:27

Zekkerj tá tirando onda!

Não demora uma semana para compilar o kernel. No caso ele está aprendendo e encontrando algumas dificuldades. Normal para quem está aprendendo.

Depois que você aprende o caminho das pedras você deixa até o seu arquivo de configuração do kernel salvo, pra não ter que ficar marcando tudo novamente.wc
Ai vai depender do seu processador, podem ser alguns minutos até algumas horas.

É coisa para entusiasta. Saber que está tirando o máximo de desempenho do sistema. Eu costumo comparar com um carro. A maioria vai querer o de fábrica mesmo. Só quer usar. Vai ter gente que vai querer customizar até os parafusos que vão no assoalho do carro.

https://youtu.be/yJzvNOuk1Ko

O vídeo acima é do meu A10. Nem precisei de uma semana, baixei um kernel já compilado com otimizações. Se tenho tempo livre as vezes compilo. Já fiz muito isso no horário do serviço. O PC tocando música e está compilando enquanto trabalho.

Para muitos esse nível de desempenho não interessa. Mas sempre gostei do meu sistema com respostas rápidas. Isso no A10. Aqui tem outro vídeo com meu antigo i7:

https://youtu.be/XpEgQvx04wc

Esse aqui é velho mas é pra mostrar que qualquer sistema pode melhorar. É um celeron:
https://youtu.be/PSMwkPC_dHc

Então dá pra escolher. Fábrica, pegar um pronto otimizado ou faça você mesmo. Se quiser um pronto tem pf-kernel, Liquorix e Xanmod.

Anderson_Coelho · 01 de Abril de 2016, 18:40

Sem querer me meter com os Mestres

, mas acho que, pelo menos para hardwares modestos, compilar pode significar poder fazer bem uma tarefa mais pesada ou então várias ao mesmo tempo. E digo isso porque já me aventurei com um C-70. De fato, o ganho de velocidade foi imperceptível, mas reproduzir vídeos, OpenGL e multitarefa deu uma boa melhorada depois da compilação. Usei um .config que veio de "fábrica" com o Mandriva instalado (dei sorte) e as dicas do tutorial do galactus para compilação.

galactus · 02 de Abril de 2016, 09:45

Pois é Anderson, eu acho legal poder fazer essas "aventuras" no Linux. Você pôde testar um kernel diferente para o seu processador. Em casos como este seu C-70 configurações agressivas não ficam bem. São processos demais para processador de menos. O meu tutorial ensina a ativar todas as instruções do processador, por isso você notou a melhora na questão da multimídia. Quanto a velocidade varia mesmo. Teria que mexer nas opções do desempenho do processador e dos escalonadores.

Anderson_Coelho · 02 de Abril de 2016, 16:40

Na verdade só acrescentei as opções do mtune e march no Makefile, pois ativar as todas as instruções tinha um efeito contrário nesse caso. Como você mesmo disse "processos demais para processador de menos". Só de curiosidade, o que seriam essas "opções do desempenho do processador"?

galactus · 02 de Abril de 2016, 19:27

É assim Anderson, quando você for compilar o kernel você terá muitas, mas muitas opções no arquivo de configuração. Como você pegou um pronto, talvez não tenha tido a curiosidade de olhar tudo.

Bom, na parte da CPU, você pode escolher:

Tipo de processador
Família do processador
Se ele tem um núcleo ou mais, com ou sem HT
O modo de Preempção - Servidor / Desktop / Desktop de baixa latência
O governador da frequência do processador - ondemand / performance
A frequência inicial do processador - 100Mhz / 300Mhz / 1000Mhz / 2000Mhz
O escalonador do processador CFS ou BFS por exemplo.

E por aí vai!

Tudo isso vai influenciar no desempenho.

Anderson_Coelho · 03 de Abril de 2016, 11:04

Ah sim, eu dei uma mexida no menuconfig sim, tirei algumas coisas e até tinha testado algumas dessas opções. No geral, naõ lembro de ter visto muita diferença (acho que não cheguei a mexer foi no escalonador pelo menuconfig), mas teria que testar melhor para ter certeza. Como o tempo de compilação era umas 2h30~3h, ficava meio difícil comparar cada opção.