Valcir Borges wrote: > Sim, estou usando o Xen. Recompilar porque preciso personalizar meu kernel > do hospedeiro e não do guest, como por exemplo: inserir suporte ao módulo > layer7,
Suporte ao módulo de layer7? Que módulo? Praticamente todos os módulos padrões do kernel já estão disponíveis no kernel padrão que você instala. Se for um módulo de terceiro, você não precisa recompilar o kernel, basta ter os pacotes kernel-headers e kernel-devel instalados, e compilar/instalar apenas o módulo específico. Note que alguns módulos não são compatíveis com o ambiente Xen, e são explicitamente removidos nesta configuração. Outra coisa, não sei que módulo de layer7 é esse que você está falando, mas não é necessário nem chegar perto de ter que recompilar o kernel para atingir esse objetivo. O netfilter provém hooks através do protocolo netlink(7)/nfnetkink para rodar tais aplicações em espaço de usuário. Além dos alvos QUEUE e NFQUEUE do iptables. > habilitar suporte a chipset SATA Se tal suporte não está operativo por padrão, é um bug do pacote, e você deveria reportar à distribuição. Todo suporte a hardware do kernel já vem (ou deveria vir) compilado e pronto para usar por padrão no pacote fornecido pela distribuição. Aqui uso Xen e SATA (módulo piix4) sem qualquer problema, usando o kernel padrão da distro. > e retirar alguns suportes > desnecessários como kernel hacking, ATM, Wi-Fi; Não faz o menor sentido. O kernel do Linux é modular. Tais módulos não são carregados a menos que você solicite, ou o subsistema hal/udev detecte que você possui o hardware que exija tais módulos. Você não vai ganhar *nada* removendo tais módulos do kernel. > Minha distro oferece sim um kernel pronto para xen, tanto que estou > usando-o. Sei que recompilar kernel nessas circunstâncias não é tarefa > simples mesmo, por isso recorro à vocês para trocar "figuras". Minha distro > é CentOS 5.2 Suspeito que você não vai achar esse tipo de ajuda facilmente. Kernel da distro é kernel da distro, foi preparado para encaixar perfeitamente com o resto do sistema, inclusive adaptações atreladas a diversos outros pacotes (gcc, glib, hal, init, mkinitrd). Nada do que você quer fazer está de acordo com a prática comum. Você pode até recompilar o kernel pela maneira padrão: baixar o .src.rpm e usar o 'rpmbuild --rebuild' (aviso: ele vai recompilar *todas* as variantes do kernel, demora e vai tomar alguns gigas do seu HD). Mas querer remover módulos aleatórios da compilação, sem entender o relacionamento íntimo do kernel com o resto do sistema, é loucura. Se você quiser alterar ou inserir um patch, você terá que entender o formato .spec, preparar um ambiente de construção (~/.rpmmacros basicamente), instalar o .src.rpm, editar o arquivo .spec para incluir seu patch no processo de compilação, e reconstruir os pacotes com 'rpmbuild -bb'. Isso tudo para: 1. correr o enorme risco do patch ser incompatível e nada funcionar; 2. não poder contar com a ajuda da comunidade ou da distribuição, pois seu kernel não será padrão; 3. não poder mais utilizar o gerenciador de pacotes para atualizar o kernel instalado, lhe transtornando sempre que nova versão do kernel for liberada. > Sim, por isso eu instalo ela pois nela todas as compilações de drivers de > rede, por exemplo, funcionam, já nos kernels oficiais não. Poderia dar exemplos? Exemplo de um driver de interface de rede que exija patch diretamente no núcleo do kernel? > Dentro desse > pacote .src.rpm tem, dentre inúmeros .patch, o kernel original da distro em > código fonte [tar.bz2]. Eu acho que faz sentido sim, pois dessa forma eu > tenho no sistema os fontes do kernel preparado para a distro, e isso evita > erros de compilações como citei acima. Você disse na outra mensagem que tentou compilar apenas o pacote fonte e o patch do Xen, e tentou fazer sua própria configuração. O "kernel original da distro" não é isso. O kernel da distribuição é o pacote fonte, mais *todos* os patches aplicados numa *ordem específica* (definida no arquivo .spec), com *opções específicas* de configuração e compilação, e *scripts específicos* para o mkinitrd. Você não pode alterar quais patches serão aplicados, ou a ordem que serão aplicados, ou quais configurações do kernel sem com isso destruir a integridade do sistema. Mesmo que você tenha sorte de conseguir compilar o kernel, é bem provável que diversos outros subsistemas quebrem ao executar sobre tal kernel. > O que eu acho que não faz sentido é > ter um kernel prédefinido pelo instalador, Um kernel que vem sendo desenvolvido e testado por uma equipe com mais de 10 anos de experiência em preparar, adaptar e construir kernels para a distro, recebendo continuamente feedback de milhares de usuários ao redor do mundo. Eu não me sinto tão inteligente para descartar um trabalho tão bem coordenado por uma equipe tão bem preparada e substituir por aquilo que eu simplesmente acho. > com um monte de suporte desnecessário, Não faz sentido. Só porque módulos foram compilados durante a construção do pacote não significa que você precisará carregá-los. > as vezes a arquitetura utilizada não é a verdadeira; CentOS oferece kernels para todas as arquiteturas que suporta: i686, i686-PAE, x86-64, Xen.i686 e Xen.x86-64. Sua arquitetura não é uma dessas? > e não poder personalizar. Existem vários níveis de personalização, e o kernel padrão, como ele é oferecido pela distribuição lhe oferece vários. Argumentos da linha de boot, seleção de quais módulos são carregados, instalação de novos módulos, alteração das variáveis do kernel pelo comando sysctl, etc. A menos que você precisasse de uma solução muito específica (que neste caso você provavelmente não estaria postando nessa lista, por diversas razões), você não deve precisar recompilar o kernel, nunca. Qualquer software que dependa de recompilação para alterar opções de usuário é considerado defeituoso, e os desenvolvedores do Linux e os empacotadores da sua distribuição sabem e concordam com isso. Se você quer remover algum recurso (que dê para ser removido) basta não carregar o módulo ou removê-lo com 'rmmod'. Se você quer adicionar algum recurso, basta instalar o módulo individualmente. Se é um recurso de terceiro, não suportado pela distribuição, instale o kernel-headers e o kernel-xen-devel e compile o módulo individualmente, sem tocar no núcleo do kernel. Se você quer alterar algum comportamento (que tenha sido projetado para ser alterado pelo usuário), basta fornecer a parâmetro na linha de boot, ou usar os comandos sysctl, ip, iptables, etc. Compilar o kernel, pelas razões que você pretende, é considerado "obsoleto" há uns 10 anos já. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. --------------------------------------------------------------------------- Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br Regras de utilização da lista: http://linux-br.conectiva.com.br FAQ: http://www.zago.eti.br/menu.html
