Perguntas Frequentes do LFS

O FAQ está dividido em três documentos. As Perguntas Frequentes gerais tem links para todas as perguntas e respostas. O FAQ do LFS é uma seleção de perguntas frequentes específicas do LFS e o FAQ do BLFS é uma seleção de perguntas frequentes específicas do BLFS.

Aprimoramentos solicitados frequentemente

Por que não incluir o FAQ no livro?

Marc Heerdink possivelmente tenha dito isso melhor em uma postagem na lfs-dev:

O problema é que o FAQ é um documento dinâmico. O FAQ para um lançamento de livro é lançado somente depois da versão do livro em si, porque o FAQ é atualizado para refletir as perguntas feitas acerca da versão atual do livro. Um link é melhor, pois você sempre terá as respostas mais atualizadas à mão.

Por que o vim está no livro?

Isso está bastante bem discutido no tópico que começa nesta postagem.

Por que não existe nenhum gerenciador de pacotes no livro?

O gerenciamento de pacotes – além daquele fornecido por tarballs e makefiles – está além do escopo do livro. Se nada mais acontecer, o número de "soluções" diferentes deveria sugerir alguns dos motivos.

Aqui estão algumas das opções:

Nenhum gerenciamento de pacotes é realmente necessário. A menos que seja desejável monitorar minuciosamente o posicionamento do arquivo do pacote, qualquer pacote grande o suficiente para garantir a remoção por motivos de espaço em disco pode ser instalado em /opt, conforme detalhado pelo FHS (talvez em /opt/foo-x.x com um link a partir de /opt/foo), e novos lançamentos geralmente podem ser instalados sobre as antigos, embora as principais atualizações e bibliotecas geralmente sejam melhor feitas reconstruindo-se o sistema de baixo para cima.
RPM, o Redhat Package Manager, é usado por diversas distribuições. Ele está disponível a partir de https://rpm.org/ e existe uma Dica do RPM para ajudar com a instalação.
Existem várias implementações de gerenciamento de pacotes no estilo de link simbólico:
- Graft está disponível a partir de https://peters.gormand.com.au/Home/tools.
- GNU Stow está disponível a partir de https://www.gnu.org/software/stow/.
O gerenciador de pacotes do NetBSD, pkgsrc, está disponível em outros sistemas, incluindo Linux. Ele está em ftp://ftp.netbsd.org/pub/pkgsrc/stable/.
Originalmente baseado em um conjunto de comandos sequenciais escritos pelo próprio Gerard Beekmans do LFS, install-log registra uma lista de arquivos instalados por um pacote à medida que o pacote é instalado. Ele está disponível a partir de https://install-log.sourceforge.net/.
CheckInstall tenta registrar chamadas de sistema feitas por "make install". Ele está disponível a partir de https://asic-linux.com.mx/~izto/checkinstall/.
pkgutils, usado pela distribuição CRUX, está disponível a partir de https://crux.nu/Wiki/FaqPkgUtils.
Existem algumas dicas disponíveis para gerenciadores de pacotes.

Se você tiver uma adição para a lista, por favor, envie uma mensagem eletrônica com o id dela, URL e outras informações para o(a) mantenedor(a) do FAQ ou para uma lista de discussão apropriada do LFS, de forma que ela possa ser adicionada aqui.

Como faço minha máquina desligar no término das atividades?

Gerenciamento de Eletricidade é uma função do núcleo; você precisa habilitá-lo no núcleo. No núcleo 5.11, você tem de habilitar as opções para ACPI (Advanced Configuration and Power Interface sob Power managerment and ACPI options. Para máquinas x86 de 32 bits muito antigas, você provavelmente irá querer as opções de APM; máquinas mais novas geralmente exigem ACPI. Certifique-se de que ou APM ou ACPI esteja habilitado no núcleo, mas, definitivamente não ambos ao mesmo tempo - isso tem sido conhecido por causar problemas, tais como nenhum dos dois realmente tendo efeito. Tente também desabilitar o SMP se você tiver somente um processador; ele também impede um desligamento adequado. Certifique-se de ler a ajuda de cada opção.

Depois de reinicializar no novo núcleo, você deveria estar apto(a) a desligar tua máquina com o comando shutdown -h now ou poweroff (leia-se também man shutdown e man halt). Se você compilou APM ou ACPI como módulos, certifique-se de que eles estejam carregados antes de tentar desligar. Algumas máquinas exigem que o APM ou ACPI seja compilado no núcleo, porque ele [o APM ou o ACPI] precisa ser inicializado durante a inicialização.

Como inicializo o LFS com UEFI?

O GRUB pode ser construído para UEFI, mas fazer isso precisa de vários pacotes além do escopo do LFS. Você pode consultar a página do BLFS para isso.

Posso ignorar um pacote do Capítulo 8, vez que ele já foi construído no Capítulo 6 ou 7 e está funcionando corretamente?

Resposta curta: não.

Resposta longa: queremos que o LFS seja "estabelecido": se algum pacote for reconstruído no sistema LFS, o resultado (bibliotecas e binários) deveria ser o mesmo que o resultado no final do livro do LFS. No Capítulo 6 as ferramentas são compiladas cruzadamente, onde muitos testes no conjunto de comandos sequenciais configure não conseguem ser feitos. O resultado "adivinhado" será usado, soluções alternativas desnecessárias serão habilitadas ou recursos opcionais serão desabilitados. As ferramentas no Capítulo 7 são construídas para resolver dependências circulares: muitos dos recursos opcionais delas dependem de pacotes ainda não construídos e tem de ser desabilitados. Portanto, reconstruí-las no Capítulo 8 é necessário.

Por outro lado, se você estiver construindo o Linux para alguma plataforma realmente pequena onde você não consegue construir pacotes em um tempo razoável (por exemplo, um ARM de 16 MHz), você pode compilar cruzadamente tudo no Capítulo 6, já que os Capítulos 7 e 8 não são aplicáveis. Ou você pode fazer os Capítulos 7 e 8 com um emulador como o QEMU.

Posso modificar o código da GCC e me livrar do /lib64?

Resposta curta: não.

Resposta longa: o LSB impõe que o carregador de ELF esteja em /lib64/ld-linux-x86-64.so.2 no x86-64.

Resposta ainda mais longa: quando o núcleo é instruído a executar um executável ELF vinculado dinamicamente, ele lê o caminho para o carregador de ELF rigidamente codificado no executável ELF, que é /lib64/ld-linux-x86-64.so.2. Portanto, se não existir, o LFS não será capaz de executar nenhum executável vinculado dinamicamente compilado em outro lugar. Por exemplo, executáveis procedentes de pacotes de software comerciais (MATLAB ou COMSOL) ou binários baixados a partir da página de lançamento do GitHub não executarão.

Voltar para o topo.

Ao ler e construir o LFS

Qual distribuição eu deveria usar para começar?

A maioria das distribuições relativamente recentes deveria servir. Você poderia consultar a página Requisitos do Sistema Anfitrião.

Certifique-se de ter instalado e (ou) atualizado os pacotes de desenvolvimento. (Procure aqueles que começam com "gcc", "glibc" ou "libstdc++" ou terminam com "-dev" ou "-devel").

Se você quiser usar o LFS como teu sistema principal e deseja instalá-lo sem primeiro instalar uma distribuição, também é possível usar uma imagem ao vivo em DVD ou pendrive. Todas as principais distribuições fornecem uma.

Como eu compilo um núcleo ou configuro módulos?

Em /usr/share/doc/linux-x.y.z ou onde quer que você desempacotou teu fonte do núcleo e a ajuda na ferramenta de configuração do núcleo (make menuconfig), veja-se o Module-HOWTO em https://www.tldp.org/HOWTO/Module-HOWTO/.

Os avisos do compilador oriundos da GCC são ruins?

Resposta curta: não.

Resposta longa: provavelmente, mas somente para alguém que trabalha no pacote que você está tentando compilar. Na maioria das vezes, tudo ficará bem, a menos que o make termine com um erro.

Aqui está um exemplo:

sk ~/tmp $ cat > Makefile
main:
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: Na função `main':
main.c:1: aviso: o tipo de retorno de `main' não é `int'
sk ~/tmp $ ######## isso funcionou ########
sk ~/tmp $
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: Na função `main':
main.c:1: erro de análise antes de `}'
make: *** [main] Erro 1
sk ~/tmp $ ######## isso falhou ########
sk ~/tmp $

Se você puder determinar que algum aviso indica um defeito real no software, informe o(a) mantenedor(a) do mesmo.

Existem informações acerca de como construir o LFS em outros processadores?

Para informações acerca de como construir o LFS para uma ampla variedade de sistemas, dê uma olhada na ramificação Cross-LFS do LFS.

Para ARM, consulte a bifurcação do LFS para ARM (64 bits ou 32 bits) ( SysV e Systemd), mantido por William Harrington; e outra ramificação ARM64 do LFS (somente 64 bits, Systemd e SysV [NÃO TESTADO!]), mantida por Xi Ruoyao.

Como eu compilo cruzadamente o LFS?

Frequentemente é útil compilar o LFS para uma máquina em outra máquina. Digamos usar aquele Athlon rápido de 1 Ghz para construir uma instalação para um 486 antigo. Embora isso tecnicamente não seja compilação cruzada, os binários compilados para o Athlon não podem ser executados no 486 porque os binários compilados para o processador mais recente usam recursos que o processador mais antigo não tem.

O livro LFS especificamente para compilação cruzada é o livro Cross-LFS. Outra fonte de informações seria a dica de compilação cruzada.

Os recursos fornecidos acima estão bastante desatualizados. Você pode modificar o processo de construção do LFS depois do LFS 10.0 (desenvolvido por Pierre Labastie) para compilação cruzada do LFS: configure $LFS_TGT para o trio de tua plataforma alvo e construa o conjunto de ferramentas cruzadas no Capítulo 5 e ferramentas temporárias no Capítulo 6 normalmente. No final do Capítulo 6, construa um núcleo e um carregador de inicialização para o alvo. Em seguida, copie o sistema temporário para a plataforma alvo, inicialize-o e continue a construção a partir do Capítulo 7. Leia-se a ramificação clfs-ng ( SysV e Systemd) para detalhes.

O que é um arquivo de texto no formato DOS?

Tem a ver com os caracteres usados para finalizar as linhas.

Existem dois que podem ser usados:

Alimentação de linha: (LF) Octal:012 Decimal:10 Hexadecimal:0A Escape no estilo C:'\n' Desce uma linha.
Retorno de carro: (CR) Octal:015 Decimal:13 Hexadecimal:0D Escape no estilo C:'\r' Move para a margem esquerda.

Unix, DOS e MacOS usam, cada um, uma combinação diferente para finalizar linhas em arquivos de texto:

Unix: apenas LF. É por isso que, quando um arquivo de texto no formato Unix é enviado para uma impressora raw, ela imprime
  como
    degraus de
      escadas.
DOS: ambos, CRLF. É por isso que se você fizer "cat -v" em um arquivo DOS, verá um "^M" (control m é retorno de carro) no final de cada linha. E é por isso que os conjuntos de comandos sequenciais não funcionam quando escritos com o Bloco de Notas da Microsoft. O núcleo procura por "/bin/sh^M" que não existe. Existe um "/bin/sh", mas nada com um "^M" anexado.
MacOS clássico (antes do Mac OS X): somente CR. As impressoras provavelmente imprimem cada linha acima da primeira, e as ferramentas Unix pensam que o arquivo inteiro é uma linha com "^M" por toda parte. O Mac OS X segue a convenção Unix (somente LF).

Para mudar de DOS para Unix, use

cp <idarquivo> <idarquivo>.dos &&
cat <idarquivo>.dos | tr -d '\r' > <idarquivo>

Ou no vim, você consegue converter um arquivo com :set ff={unix, dos, mac}. Outras conversões provavelmente exigirão sed ou um uso diferente de tr e serão deixadas como exercício para o(a) leitor(a).

Existe uma maneira de baixar todos os arquivos atuais de uma vez?

Sim. Você consegue baixar o arquivo LFS-BOOK-x.y-wget-list https://www.linuxfromscratch.org/lfs/downloads/stable/wget-list. Para baixar todos os arquivos, use a versão do wget na tua distribuição anfitriã para executar:

wget --input-file=LFS-BOOK-x.y-wget-list

Voltar para o topo.

Erros gerais de compilação

Quando usar sinalizadores de otimização (configurando a CFLAGS)

Se você estiver recebendo erros e estiver configurando CFLAGS ou, do contrário, passando sinalizadores de otimização para o compilador, esse possivelmente seja o problema.

Se você perguntar na lista e eles(as) não conseguirem descobrir imediatamente, provavelmente sugerirão tentar sem otimização. Portanto, se você apenas tentar novamente sem antes perguntar, estará um passo à frente deles(as) :)

Digno de observação é que a otimização de binutils, gcc ou glibc possivelmente faça com que qualquer outro pacote falhe para compilar ou executar ou, do contrário, se comporte mal de maneiras estranhas e misteriosas. Além disso, a otimização que funciona para outra pessoa possivelmente não funcione para você. Sinalizadores que costumavam funcionar possivelmente parem de funcionar misteriosamente. Mesmo algumas pequenas mudanças inocentes no hardware podem fazer a diferença.

(Se você não sabe o que são sinalizadores de otimização, não se preocupe, você realmente não precisa).

A saída gerada do configure mostra erros; "gcc -V" não está errado?

Para determinar o que está presente no sistema, os conjuntos de comandos sequenciais de configuração tentam vários comandos com várias opções de linha de comando. Eles então executam ações dependendo do código de saída dos comandos. Alguns desses comandos podem escrever mensagens de erro, e é isso que você vê, por exemplo, com "gcc -V". Mas o conjunto de comandos sequenciais de configuração em si não falhou.

Por que o GCC informa "Erro interno do compilador" para um programa "olá mundo"?

Você superotimizou o gcc.

Eu não excluí a árvore do fonte depois da minha tentativa mais recente. Eu preciso?

Sim. Em geral, make clean ou make dist-clean não são confiáveis para fontes limpos. Especialmente quando você hackeou manualmente os fontes ou aplicou remendos, você deveria primeiro tentar novamente com um novo pacote desempacotado. A única exceção a essa regra é o núcleo Linux, que exige que os fontes dele estejam presentes quando módulos de terceiros(as), como os controladores NVidia, são necessários.

Eu estou obtendo `/dev/null: Permissão negada'

/dev/null se parece com isto:

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Aug 3 2000 /dev/null

Se não, deveria. Consulte-se "configure: loading cache /dev/null" no config.log.

Se parecer certo, o problema provavelmente está nas tuas opções de montagem. Veja-se a resposta para "./configure: mau intérprete: Permissão negada", acima.

sinal 11 (erro interno: Falha de segmentação)

A resposta longa está em https://www.bitwizard.nl/sig11/.

A resposta curta é que se a reiniciação do make for um pouco mais longe a cada vez, você tem um problema de hardware. (Se o make, ou o que quer que você esteja executando, falhar sempre no mesmo lugar, então não é hardware).

Primeiro, não faça overclock demais da CPU. Observe que, com uma CPU Intel "K" (desbloqueada), mesmo a configuração padrão da placa-mãe geralmente já está em overclock, de forma que você possivelmente precise até mesmo retroceder a partir do padrão, especialmente quando a CPU está abaixo da média: a diferença individual entre todas as CPUs de um mesmo modelo pode ter um efeito significativo na capacidade de overclock, portanto, comprar uma CPU desbloqueada é uma espécie de jogo.

Supondo que você não esteja fazendo overclock, o problema de hardware mais provável é memória ruim, que você consegue verificar com Memtest86+ oriundo de https://www.memtest.org/.

O superaquecimento da CPU é outro problema comum de hardware. Certifique-se de que o cooler esteja instalado corretamente com pasta térmica aplicada. E alguns coolers (especialmente coolers líquidos multifuncionais) não podem ser configurados via BIOS e precisam de controlador de núcleo e (ou) software especial (por exemplo, liquidctl) para configurar os parâmetros corretamente. Se esse cooler não estiver configurado corretamente, ele poderá funcionar em uma velocidade mais baixa (ou nem funcionar). Se o cooler já estiver funcionando em velocidade máxima, mas a CPU ainda superaquecer, atualize o cooler ou faça downclock da CPU via BIOS.

Se a memória ruim e o superaquecimento da CPU puderem ser descartados, veja-se a resposta longa.

“Esse arquivo ou diretório não existe” tentando fazer chroot

Exemplo desse erro é:

/usr/bin/env: /bin/bash: No such file or directory

Se você tem certeza de que $LFS/bin/bash existe, o que acontece provavelmente é que o caminho para o caminho do vinculador dinâmico incorporado no executável seja /lib64/ld-linux-x86-64.so.2 (/lib/ld-linux.so.2 para 32 bits), e quando alguém vai executar o binário dentro do chroot onde /lib64/ld-linux-x86-64.so.2 ainda não existe, a mensagem de erro muito inútil No such file or directory é exibida.

Verifique se o link simbólico $LFS/lib64/ld-linux-x86-64.so.2 (deve ter como alvo ../lib/ld-linux-x86-64.so.2 ou ../lib/ld-linux.so.2 para 32 bits) e (ou) $LFS/lib (deveria ter como alvo usr/lib) estão quebrados. Observe que esses links simbólicos precisam ser relativos (ou seja, deveriam ser ../lib/ld-linux-x86-64.so.2, não $LFS/lib/ld-linux-x86-64-so.2), de forma que eles ainda sejam válidos no ambiente chroot.

bash: ./configure: Esse arquivo ou diretório não existe

Você se esqueceu de mudar de diretório (cd) para dentro do diretório extraído do pacote depois de extraí-lo.

./configure: mau intérprete: Permissão negada

Você provavelmente está recebendo isso enquanto constrói binutils no Capítulo 5 do Livro LFS. O problema provavelmente está nas tuas opções de montagem. Você provavelmente tem uma linha no /etc/fstab como:

/dev/sda10 /mnt/lfs ext2 user 1 2

'user' é o sinalizador de montagem e é o problema. Para citar a página de manual do mount:

user: Permitir que um(a) usuário(a) comum monte o sistema de arquivos. Essa opção implica as opções noexec, nosuid e nodev (a menos que substituídas por opções subsequentes, como na linha de opções user,exec,dev,suid).

Portanto, mude a linha no /etc/fstab como isto:

/dev/sda10 /mnt/lfs ext2 defaults 1 2

configure não consegue adivinhar meu tipo de dispositivo.

Sintomas típicos se parecem com isto:

sk ~/tmp-0.0 $ ./configure
creating cache ./config.cache
checking host system type...
configure: error: can not guess host type; you must specify one
sk ~/tmp-0.0 $

O problema geralmente é que o conjunto de comandos sequenciais não consegue executar o compilador. Geralmente é apenas um link simbólico /usr/bin/cc ausente. Você consegue consertar isso assim:

cd /usr/bin && ln -s gcc cc

Se isso não funcionar, verifique o arquivo config.log criado pelo configure. Os erros são registrados lá e possivelmente indiquem o problema.

verificando se estamos usando GNU C... não

Se você estiver recebendo um erro oriundo do configure como:

verificando se estamos usando GNU C... não
configure: erro: GNU libc precisa ser compilada usando GNU CC

Pode ser porque o grep não está funcionando. Para testar se o grep está funcionando no ambiente chroot, execute o seguinte comando a partir de dentro do chroot:

grep -E root /etc/passwd

Se não imprimir a linha do root a partir do /etc/passwd, novamente, você tem um problema. (Esse teste também funciona se você encontrar o problema depois de reinicializar no novo sistema LFS).

O sistema não tem mais ptys. Peça para o(a) administrador(a) do sistema criar mais.

Se isso acontecer no ambiente chroot do LFS, certifique-se de que teu núcleo do anfitrião suporta o pseudo terminal UNIX 98 (todas as distribuições de área de trabalho ou servidores não tão antigas deveriam suportá-lo) e que os sistemas de arquivos virtuais do núcleo tenham sido montados corretamente antes de entrar no ambiente chroot.

Se isso acontecer no sistema completo construído seguindo a revisão SysV do livro LFS, é provável que você tenha perdido a linha para o sistema de arquivos devpts no /etc/fstab.

./config.status: line 508: 0a1,66: comando não encontrado (ou qualquer mensagem semelhante com apenas números diferentes)

Verifique se config.log contém "configure: carregando cache /dev/null". Se for o caso, consulte a entrada.

"configure: carregando cache /dev/null" no config.log

Se isso acontecer no ambiente chroot do LFS, é provável que você tenha esquecido de montar /dev vinculado ao $LFS/dev em "Preparando Sistemas de Arquivos Virtuais do Núcleo".

Saia do ambiente chroot primeiro. Em seguida, execute ls -l /dev/null. Isso deveria gerar algo como crw-rw-rw- 1 root root 1, 3 {alguma data} /dev/null. Especialmente, a primeira letra c e os números 1, 3 precisam estar corretos. Caso contrário, significa que tua distribuição anfitriã está de alguma forma quebrada (isso possivelmente aconteça se você usou o perigoso comando rm -rf $LFS/* ou similar quando /dev foi montado vinculado). Para uma distribuição anfitriã moderna, isso pode ser corrigido reinicializando-se (um /dev quebrado possivelmente impeça a reinicialização normal e você possivelmente precise usar o botão reset). Para uma distribuição anfitriã muito antiga, você possivelmente precise reinstalá-la (então por que não atualizar para uma moderna? :)

Agora sabemos que a distribuição anfitriã está sã. Certifique-se de que $LFS esteja configurada corretamente e que a partição LFS seja montada primeiro. Use umount -R $LFS/dev para desmontar $LFS/dev (caso você tenha montado algo errado lá) e, então, remova tudo em $LFS/dev e siga a seção "Preparando Sistemas de Arquivos Virtuais do Núcleo" para montar $LFS/dev e $LFS/dev/pts corretamente. Depois que estiverem montados, você pode entrar novamente no ambiente chroot e continuar.

Voltar para o topo.

Erros específicos de pacote

M4: Valor assumido de MB_LEN_MAX errado

Essa mensagem de erro geralmente indica que o limits.h fornecido pelo GCC não está incluindo o limits.h oriundo da Glibc como deveria. Existe um comando como solução alternativa para limits.h no GCC Passagem 1. Não se esqueça de executar o comando.

No LFS 10.0 até 11.3, existe outro comando como solução alternativa executando-se mkheaders depois de instalar a Glibc (Capítulo 5). Esse comando foi removido no LFS 12.0. Executar esse comando construindo o LFS 12.0 ou posterior (provavelmente por causa do reuso de conjuntos de comandos sequenciais antigos - observe que tal reuso é fortemente desencorajado) ou esquecer esse comando construindo o LFS 10.0 a 11.3 também levará a essa mensagem de erro.

Se você tiver encontrado esse problema, desempacote o tarball do GCC novamente e execute o comando na parte inferior da página GCC Passagem 1 para criar o limits.h. Então, se você estiver construindo o LFS 12.0 ou posterior, execute rm -f $LFS/tools/lib/gcc/$LFS_TGT/*/include-fixed/limits.h que corrigiria o problema caso você tivesse erroneamente executado o comando mkheaders que não pertence à versão do LFS que você está construindo. Se você estiver construindo o LFS 11.0 até 11.3, execute o comando mkheaders na Glibc do Capítulo 5.

Systemd: systemd-networkd.service: Falha ao determinar as credenciais de usuário(a): esse processo não existe

Provavelmente é porque /etc/passwd para revisão sysv seja mal usado em sistemas baseados em systemd. "Esse processo não existe" é apenas a mensagem de erro "padrão" para ESRCH; ela não é muito útil para o diagnóstico desse problema.

Voltar para o topo.

Problemas de configuração e inicialização

Pânico de núcleo - não sincronizando: VFS: Não é possível montar o root fs em ...

Existem várias razões pelas quais o núcleo estaria inapto para montar o sistema de arquivos raiz.

Você especificou a partição correta em /boot/grub/grub.cfg?
O suporte para a unidade rígida está habilitado no núcleo? Para SCSI isso significa suporte para o adaptador específico SCSI.
O suporte para a unidade rígida está compilado internamente no núcleo, não apenas como um módulo? (Os módulos são armazenados no sistema de arquivos. Se um controlador necessário para acessar o sistema de arquivos for armazenado como um módulo nesse sistema de arquivos, bem... você sabe... ;)
O suporte para o sistema de arquivos está compilado internamente no núcleo? Novamente, não um módulo? O suporte para ext4 está habilitado por padrão, mas outros, como reiser, jfs e xfs, não estão.

init: Id "1" regerando muito rápido: desativado por 5 minutos

Quando você vir, em teus registros do sistema, esta linha:

init: Id "1" respawning too fast: disabled for 5 minutes

Isso significa que você tem um erro na linha do /etc/inittab que começa com o id fornecido ("1" nesse exemplo).

eth0:interface desconhecida:Não existe tal dispositivo [falhou]

O erro completo se parece com isto:

eth0:unknown interface:No such device [failed]
Setting up default gateway...
SIOCADDRT:No such device [failed]

eth0 é um dispositivo virtual sem entrada de /dev. Refere-se à primeira placa de rede de intercomunicação detectada em teu sistema. A razão pela qual o núcleo não consegue encontrar esse dispositivo é porque você se esqueceu de adicionar suporte para tua placa de rede de intercomunicação no núcleo. O núcleo detectou a placa, mas não tem um controlador para ela. O conjunto de comandos sequenciais de inicialização do LFS tenta ativar a rede de intercomunicação, mas falha por causa disso.

Recompile teu núcleo com o controlador apropriado, integrado ou como um módulo. Se você compilou o controlador de rede de intercomunicação como um módulo, então ajuste também o /etc/modules.conf para apelidar o módulo da placa de rede de intercomunicação como eth0; por exemplo: alias eth0 8139too. Se não souber qual placa de rede de intercomunicação tem, você pode usar dmesg, /proc/pci ou lspci para descobrir.

E o udev possivelmente renomeie teus dispositivos de rede de intercomunicação. Por exemplo, eth0 possivelmente seja renomeado para enp4s0. Você pode executar o comando ip link depois de inicializar o sistema LFS e examinar a saída gerada para saber o nome dos teus dispositivos de rede de intercomunicação.

IRQ 9: ninguém se importou (tente inicializar com a opção "irqpoll")

Possivelmente seja um defeito no firmware (BIOS) ou nos controladores no núcleo. Alguns(as) fornecedores(as) de hardware tendem a usar hacks específicos do Windows no BIOS deles(as), o que é mal interpretado pelo núcleo Linux e causa esse tipo de problema.

Se você vir uma mensagem como essa, mas teu sistema funcionar normalmente, você pode ignorá-la. Se o sistema funcionar erradamente, você pode tentar as combinações de várias opções do núcleo para contornar: irqpoll, noapic, pci=nocrs e i8042.nopnp=1.

E, pode tentar substituição DSDT da ACPI se você realmente entendê-la.

Você sempre pode informar esse tipo de problema para rastreador de defeitos do Núcleo, não importa se for um defeito de BIOS. Os(As) desenvolvedores(as) do núcleo querem tornar o Linux executável mesmo que o BIOS tenha esse tipo de defeito.

O sistema LFS está muito mais lento que a distribuição anfitriã (ou outra distribuição)

Se o sistema LFS estiver mais lento que outra distribuição, mas não muito mais lento, é normal. Nós focamos em construir um sistema Linux a partir do código-fonte e não fazemos nada para ajustar o sistema para melhorias marginais de desempenho. As outras distribuições possivelmente habilitem otimizações adicionais do compilador, ajustem opções do núcleo (via sysctl) ou usem outras abordagens para extrair mais desempenho. E o LFS usa um lançamento mais recente do GCC, que provavelmente é mais lento que um lançamento antigo do GCC. Um novo lançamento do GCC frequentemente tenta otimizar o código-alvo mais intensamente (essas otimizações desacelerarão a compilação, mas esperançosamente tornarão o programa compilado mais rápido). Portanto, o LFS levará mais tempo construindo um pacote grande (como o núcleo Linux).

Mas, se o sistema LFS estiver muito lento (por exemplo, levar 5 horas para construir um núcleo, enquanto a distribuição anfitriã precisa de somente uma hora para construir o mesmo núcleo com exatamente a mesma configuração), isso provavelmente indica um problema de escala de frequência dinâmica da CPU. Você consegue monitorar o valor de "cpu MHz" em /proc/cpuinfo para ver se tua CPU está executando em uma frequência razoável enquanto uma carga de trabalho (como construir o núcleo) está executando na CPU.

Se tua CPU estiver executando em uma frequência muito menor que a esperada (um Intel Core i3 construindo o núcleo, mas executando a somente 800 MHz é definitivamente lento demais), tente ajustar a configuração de "Default CPUFreq governor" na configuração do núcleo e reconstrua o núcleo. A configuração ideal deveria limitar a CPU a uma frequência baixa quando o sistema estiver ocioso, mas aumentá-la para o desempenho máximo enquanto uma carga de trabalho estiver executando.

Observe que um regulador possivelmente se comporte diferentemente em CPUs diferentes. Por exemplo, o regulador "powersave" possivelmente funcione bem para um modelo de CPU, mas trave outra CPU em 800 MHz, não importando se existe uma carga de trabalho executando. Se você não conseguir (ou não quiser gastar muito tempo para) encontrar uma configuração ideal, use o regulador "performance".

Em um processador moderno Intel ou AMD, a "preferência de desempenho elétrico" também pode ter um impacto significativo no desempenho. A configuração padrão geralmente é "desempenho de equilíbrio", o que pode reduzir severamente o desempenho, especialmente quando a CPU tem muitos elementos de processamento, mas somente uns poucos elementos de processamento são utilizados (por exemplo, ao medir a UPC com make -j1 em um Core i9-13900K). A maneira mais fácil de gerenciar a preferência de desempenho elétrico é por meio do power-profiles-daemon, leia-se power-profiles-daemon (SysV) ou power-profiles-daemon (Systemd) para como instalá-lo e usá-lo. Alternativamente, você pode tentar mudar essa configuração por meio do BIOS se uma entrada de configuração for fornecida.