Se seu kernel fizer coisas realmente esquisitas após uma atualização de kernel rotineira, você provavelmente se esqueceu de rodar o comando make clean antes de compilar o novo kernel. Os sintomas deste problema podem ser algo desde um congelamento imediato, passando por problemas estranhos de E/S, indo até problemas de desempenho. Certifique-se também de rodar make dep, além de make clean.
Se seu kernel estiver consumindo muita memória, for muito grande e/ou simplesmente leva uma eternidade para compilar mesmo em seu Escovium-VI de 500 GHz, você provavelmente tem uma pá de coisas desnecessárias configuradas (drivers de dispositivo, sistemas de arquivo, etc). Se você não as utiliza, não as configure, porque elas realmente ocupam memória. O sintoma mais óbvio de um kernel inflado demais é uma grande atividade de permuta (`swap') entre a memória e o disco; se seu disco estiver fazendo muito barulho e não for um daqueles antigos Fujitsu Eagle que soam como um avião a jato pousando quando são desligados, dê uma revisada em sua configuração de kernel.
Você pode descobrir quanta memória seu kernel está utilizando subtraindo a quantidade total de memória em sua máquina da quantidade ``total mem'' mostrada em /proc/meminfo ou na saída do comando `free'.
Note que a quantidade total de memória de sua máquina pode não ser igual à memória fisicamente instalada. Algumas placas-mãe utilizam parte de sua memória para armazenar o buffer de vídeo. Caso sua placa-mãe tenha um controlador gráfico embutido, não se esqueça de verificar esta possibilidade. Normalmente, esta quantidade de memória pode ser visualizada numa das mensagens da BIOS durante o processo de inicialização da máquina, ou no prórpio programa de configuração da BIOS.
Opções de configuração para PCs são: primeiro, na catagoria `General Setup' (Configurações Genéricas), selecione `Parallel port support' (suporte à porta paralela) e `PC-style hardware' (hardware compatível com PC). Então, em `Character devices' (dispositivos de caracteres), selecione `Parallel printer support' (suporte a impressoras paralelas).
Há também a questão dos nomes. No Linux 2.2, os dispositivos de impressora têm nomes diferentes daqueles das versões anteriores. O resultado prátido disto é que se você tinha uma lp1 num kernel antigo, ela provavelmente se chama lp0 no novo. Use o comando `dmesg' ou dê uma olhada nos logs em /var/log para certificar-se.
Se não compila, é provável que algum patch tenha falhado, ou seu fonte esteja corrompido de alguma forma. Sua versão de gcc também pode não ser a correta, ou também pode estar corrompida (por exemplo, os arquivos de inclusão -- include files -- podem estar trocados). Certifique-se de que os links simbólicos que o Linus descreve no README estejam lá e apontando para os locais corretos. Em geral, se um kernel padrão não compila, algo está muito errado com o sistema, e provavelmente será necessária a reinstalação de certas ferramentas.
Em alguns casos, o gcc pode falhar devido a problemas de hardware. A mensagem de erro será algo como ``xxx exited with signal 15'' (xxx foi termindado por um signal 15) e geralmente parecerá algo bem misterioso. Eu provavelmente não mencionaria isto, mas já me aconteceu uma vez - eu tive uma memória cache com problemas, e o compilador ocasionalmente reclamava de coisas aleatórias. Tente reinstalar o gcc primeiro, se você encontrar problemas. Você só deve suspeitar de problemas em hardware se seu kernel compilar direito com o cache externo desligado, ou com uma quantidade menor de memória RAM, etc.
Algumas pessoas tendem a ficar perturbadas quando se sugere que seu hardware está com problemas. Bem, eu não estou inventando isto. Há um FAQ (`Frequently asked questions', ou `perguntas frequentes') sobre isto em http://www.bitwizard.nl/sig11/.
Você não rodou o LILO (ou GRUB, ybin, quik, ou o gerente de inicialização que você usa), ou ele não está configurado corretamente. Uma coisa que me ``pegou'' uma vez foi um problema no arquivo de configuração (`/etc/lilo.conf'); havia uma linha `boot = /dev/hda1', ao invés de `boot = /dev/hda'. Pode ser bastante chato inicialmente, mas uma vez que você tenha um arquivo de configuração que funcione, não deverá ser necessário alterá-lo.
Opa! A melhor coisa que você pode fazer aqui é inicializar a partir de um disquete ou CDROM e preparar outro disquete (por exemplo, `make zdisk' resolve). Você precisa saber onde seu sistema raiz (/) está e de que tipo ele é (ext2, ext3, minix, etc). No exemplo abaixo, você também precisa saber em qual sistema de arquivos a sua árvore de fontes /usr/src/linux está, seu tipo, e onde ele normalmente é montado.
No exemplo seguinte, / está em /dev/hda1 e o sistema de arquivos que contém /usr/src/linux é /dev/hda3, normalmente montado no /usr. Ambos são sistemas de arquivos do tipo `second extended' (ext2). A imagem de kernel que funciona tem o nome bzImage e está em /usr/src/linux/arch/i386/boot.
A idéia é que se houver um bzImage que funcione, será possível utilizá-lo no novo disquete. Outra alternativa, que pode ou não funcionar melhor (depende do método particular que você usou para ferrar com seu sistema) será discutida após o exemplo.
Primeiro, inicialize a partir de um disquete boot/root (isto é, um disquete de inicialização contendo também um sistema de arquivos raiz) ou um disquete de recuperação (`rescue disk') e, em seguida, monte o sistema de arquivos que contém a imagem de kernel que funciona:
mkdir /mnt mount -t ext2 /dev/hda3 /mnt
Se o mkdir lhe disser que o diretório já existe, simplesmente ignore o fato. Agora, mude para o diretório (`cd') onde a imagem de kernel que funciona estava. Note que /mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot. Coloque um disquete formatado (não o seu disquete de inicialização ou raiz!) no seu drive ``A:'', coloque a imagem no disquete e configure-a para usar seu sistema de arquivos raiz:
cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1
Mude para o diretório raiz (`cd /') e desmonte o sistema de arquivos normalmente usado em seu /usr:
cd / umount /mnt
Você agora deve ser capaz de reinicializar seu sistema normalmente a partir deste disquete. Não se esqueça de rodar o lilo (ou o que quer que você tenha feito ou deixado de fazer) após a reinicialização!
Conforme mencionado acima, há outra alternativa muito comum. Se você por acaso tiver uma imagem de kernel que funcione no diretório / (/vmlinuz por exemplo), você pode usá-la num disquete de inicialização. Supondo que todas as condições acima são atendidas e que minha imagem de kernel é /vmlinuz, simplesmente faça as seguintes alterações ao exemplo acima: mude /dev/hda3 para /dev/hda1 (o sistema de arquivos /), /mnt/src/linux para /mnt, e if=bzImage para if=vmlinuz.
Usar versões não muito recentes de LILO com drives muito grandes (mais de 1024 cilindros) pode causar problemas. Atualize sua versão de LILO ou procure ajuda na documentação do LILO ou no LILO mini-HOWTO.
Isto é, `cuidado: bdflush não está rodando'. Este pode ser um problema sério. A partir da versão 1.0 do kernel (lançada por volta de 20 de abril de 1994), um programa chamado `update', que periodicamente grava os buffers dos sistemas de arquivos, foi atualizado/substituído. Nos kernels atuais, este programa foi substituído por um processo de kernel (na verdade, um `thread' do kernel). Se seu kernel for MUITO antigo, obtenha os fontes do `bdflush' (devem estar disponíveis no mesmo local de onde você obteve seus fontes do kernel), e instale-o (você provavelmente vai querer rodar com seu kernel antigo enquanto faz isto). Ele se instala como `update' e, após uma reinicialização, o novo kernel não deverá reclamar. Em kernels razoavelmente novos, você não deverá ter este tipo de problema.
Estranhamente, muita gente não consegue fazer com que seus drives ATAPI funcionem, provavelmente porque há muitas coisas que podem dar errado.
Se seu drive de CD-ROM for o único numa dada interface IDE, ele deve ser jumpeado como ``master'' ou ``single''. Aparentemente, o erro mais comum é não jumpeá-lo apropriadamente.
Com placas de som antigas, há o problema das interfaces IDE. A Creative Labs (para mencionar uma) pôs interfaces IDE em algumas de suas placas de som. Entretanto, isto leva a um problema interessante: a maioria das placas-mãe atuais (e muitas meio antiguinhas) têm duas interfaces IDE embutidas (nos IRQs 14 e 15, normalmente), de modo que uma prática comum é configurar a interface da placa de som como uma terceira interface IDE (tradicionalmente IRQ 11).
Isto causa problemas com versões muito antigas de Linux, já que o suporte a uma terceira interface IDE só apareceu a partir da série 1.3.x (que era de desenvolvimento, lembre-se), e não havia `auto-probe', isto é, o Linux não tentava detectar em seu sistema uma terceira interface IDE, mesmo que ela estivesse presente. Para contornar isto, você tem algumas escolhas.
Se você tem uma segunda porta IDE (a maioria das placas-mãe atualmente têm), há chances de que você não a esteja usando ou que não hajam dois dispositivos já ligados nela. Retire seu drive ATAPI da placa de som e ligue-o à segunda interface. Você pode então desabilitar a interface da placa de som, o que até economiza uma linha de IRQ.
Se você não tiver uma segunda interface, configure a interface IDE da placa de som (não a parte de som da placa) como a segunda interface (usando IRQ15 e porta 0x178). Deve funcionar.
Se seu kernel reclama de `obsolete routing requests', obtenha uma versão mais nova do programa route e demais programas que fazem manipulação de rotas. O arquivo /usr/include/linux/route.h (que na verdade é um arquivo em /usr/src/linux) foi alterado.
Atualize seu kernel ao menos para a versão 1.2.1.
Não utilize o arquivo vmlinux criado em /usr/src/linux como sua imagem de inicialização; o arquivo correto é [..]/arch/i386/boot/bzImage.
Altere a palavra dumb para linux na entrada do console no arquivo /etc/termcap. Você talvez tenha de criar uma entrada terminfo também.
Os fontes do kernel do Linux contém vários arquivos de inclusão (`include files', aqueles cujos nomes terminam em .h), que são referidos pelos arquivos de inclusão padrão do diretório /usr/include. Normalmente, refere-se a eles assim (onde xyzzy.h seria um arquivo no diretório /usr/include/linux): #include <linux/xyzzy.h> Normalmente, há um link chamado linux em /usr/include apontando para o diretório include/linux de sua árvore de fontes do kernel (/usr/src/linux/include/linux num sistema típico). Se este link não estiver lá, ou apontar para o local errado, a maioria dos programas simplesmente não poderá ser compilada. Se você achou que os fontes do kernel estavam tomando muito espaço em disco e apagou-os, isto obviamente será um problema. Outra coisa que pode estar errada são as permissões de acesso aos arquivos; se o usuário root tiver uma umask que não permite que outros usuários leiam seus arquivos por default, e se você extraiu os fontes do kernel sem a opção p (`preserve filemodes' - preservar modos de arquivos), os usuários também não serão capazes de utilizar o compiladore de C. Embora você possa utilizar o comando chmod para resolver este problema, provavelmente será mais fácil re-extrair os arquivos de inclusão. Você pode fazer isto da mesma maneira como você extraiu o pacote inteiro de fontes no começo, apenas com um argumento adicional:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include Nota: ``make config'' regerará o link /usr/src/linux se ele não estiver lá.
Os seguintes comandos de exemplo podem ser úteis para os que estão imaginando como ampliar (ou restringir, se for o caso) alguns limites impostos pelo kernel: echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages