Linux From Scratch: conhecimento mínimo e roteiro completo para construir seu próprio Linux

Construir um Linux From Scratch (LFS) significa partir de uma distribuição Linux já funcional, compilar uma cadeia de ferramentas isolada e então usá-la para montar um novo sistema GNU/Linux, pacote por pacote. O objetivo deste guia é explicar o mínimo que você precisa saber antes de começar, o que deve fazer durante cada etapa, como reconhecer erros e o que ainda falta depois que o LFS finalmente inicia.

Este texto é um mapa de execução e aprendizagem. Ele não substitui os comandos exatos do livro oficial: as versões, correções e opções de compilação formam um conjunto testado e precisam ser seguidas na mesma edição. Em 21 de julho de 2026, a edição estável recomendada é o LFS 13.0 com systemd, publicada em 5 de março de 2026. O ramo de desenvolvimento muda continuamente e não é a escolha certa para a primeira construção.

Resumo executivo

O caminho mais seguro para a primeira experiência é construir o LFS em uma máquina virtual x86-64, com firmware BIOS legado, 4 vCPUs, 8 GB de RAM, um disco virtual separado de 60 a 80 GB e uma distribuição Linux recente como hospedeira. Tire snapshots antes do particionamento, antes do chroot e antes de instalar o carregador de inicialização. Só use hardware real depois de concluir uma construção inteira com sucesso.

O projeto oficial recomenda pelo menos quatro núcleos e 8 GB de memória. Máquinas menores ainda podem funcionar, mas compilam mais lentamente. O sistema base pronto não é uma distribuição de desktop: ele entrega toolchain, bibliotecas, shell, utilitários, kernel, systemd, configuração básica e boot. Navegador, interface gráfica, áudio, Wi-Fi conveniente, impressão, Bluetooth, sudo, firewall, servidor SSH e muitos outros recursos pertencem ao Beyond Linux From Scratch (BLFS).

Atenção à segurança: “estável” significa uma edição coerente e testada, não um conjunto de fontes congelado que permanece seguro para sempre. A página de avisos do LFS e BLFS já registra correções posteriores ao lançamento 13.0, inclusive de gravidade alta ou crítica. Antes de baixar os fontes, aplique exatamente as substituições e patches indicados para a edição; não use cegamente o pacote original nem troque por qualquer versão mais nova.

Os cinco princípios que mais evitam fracassos são:

Use uma única versão estável do livro do começo ao fim. Não reutilize scripts ou comandos de outra edição.
Entenda em qual contexto cada comando roda: usuário normal, root no hospedeiro, usuário lfs, ou root dentro do chroot.
Confira sempre $LFS, ponto de montagem, usuário atual e diretório atual antes de comandos de instalação ou remoção.
Não pule testes importantes, principalmente de Binutils, GCC e Glibc; compare falhas esperadas com os logs oficiais.
Registre tudo. Versão do livro, comandos, horários, resultados de testes, desvios e checkpoints tornam a recuperação possível.

Se a finalidade for apenas possuir um Linux pequeno e personalizado, Arch, Gentoo, Debian minimal ou Buildroot provavelmente resolverão com menos manutenção. Faça LFS principalmente para aprender como compilador, linker, libc, hierarquia de arquivos, chroot, kernel, init e boot se encaixam.

Metodologia e critérios

Esta pesquisa foi construída prioritariamente a partir do livro Linux From Scratch 13.0-systemd, do PDF oficial da mesma edição, do BLFS 13.0, das erratas, dos avisos de segurança, do FAQ e dos logs de compilação do projeto.

Foram separados três tipos de orientação:

Exigência oficial: comportamento ou requisito declarado pelo projeto LFS.
Recomendação prática: medida conservadora para reduzir risco, como trabalhar em máquina virtual e manter snapshots.
Escolha pessoal: decisão que depende do propósito do sistema, como esquema de partições ou gerenciador de pacotes.

Os comandos deste artigo servem para preparar e conferir o ambiente. Os comandos de compilação de cada pacote devem ser copiados da edição estável aberta durante a construção. Isso reduz um dos erros mais perigosos do LFS: combinar nomes de pacotes, patches e opções provenientes de edições diferentes.

1. O que o LFS é — e o que ele não é

O que você realmente constrói

Ao terminar o livro básico, você terá um sistema inicializável contendo, entre outros componentes:

kernel Linux configurado para a máquina;
Glibc, carregador dinâmico e bibliotecas fundamentais;
GCC, Binutils, Make e ferramentas para continuar compilando software;
Bash e utilitários GNU essenciais;
sistema de arquivos conforme a hierarquia esperada pelo Linux;
usuários e grupos básicos;
systemd e serviços fundamentais;
regras de dispositivos, rede básica e arquivos de configuração;
GRUB no fluxo BIOS tratado pelo livro principal;
documentação e manuais essenciais.

O livro não baixa uma distribuição pronta e não “remasteriza” Debian ou Fedora. O hospedeiro fornece apenas o kernel em execução e as primeiras ferramentas. A construção cria uma toolchain própria, reduz progressivamente a dependência do hospedeiro, entra em chroot e recompila o sistema final dentro do novo ambiente.

O que não vem pronto

LFS não oferece, por padrão:

instalador gráfico;
repositório binário ou atualizador automático;
resolvedor de dependências;
desktop KDE Plasma ou GNOME;
navegador e suíte de escritório;
configuração automática de Wi-Fi;
firmware para todo hardware;
Secure Boot pronto;
política completa de hardening;
ciclo de atualizações semelhante ao de uma distribuição comercial.

Essas lacunas não são defeitos: o propósito do projeto é educativo. O BLFS continua onde o LFS termina e ensina a adicionar rede, segurança, armazenamento, servidores, interface gráfica, multimídia e aplicações.

Quando vale a pena

LFS é excelente para aprender:

por que uma toolchain precisa ser autoconsistente;
como headers do kernel, libc, compilador, assembler e linker se relacionam;
como um executável encontra seu interpretador e suas bibliotecas;
o que acontece antes e depois de um chroot;
como /dev, /proc, /sys e /run são disponibilizados;
como o kernel, o sistema init, o fstab e o bootloader trabalham juntos;
por que uma distribuição precisa de política de pacotes, segurança e atualização.

Não é a rota mais eficiente para um servidor de produção. Um LFS exposto à internet exige que você acompanhe vulnerabilidades, reconstrua pacotes e controle dependências por conta própria.

2. O conhecimento mínimo antes de começar

Você não precisa ser especialista em C, mas deve operar confortavelmente no terminal. Se os itens abaixo forem desconhecidos, pratique primeiro em uma VM comum.

Shell e administração

Você deve saber:

navegar com pwd, cd, ls e localizar arquivos;
copiar, mover e remover arquivos conscientemente;
entender caminho absoluto, caminho relativo, variável e expansão do shell;
usar redirecionamentos como >, >>, <, 2>&1 e pipelines;
diferenciar usuário normal, root, sudo, su e shell de login;
interpretar permissões, dono, grupo, chmod, chown e umask;
extrair arquivos .tar.gz, .tar.xz e aplicar patches;
ler mensagens de configure, make e testes sem reagir a toda advertência como se fosse erro;
editar arquivos com Vim, Nano ou outro editor de terminal;
obter ajuda com man, info, --help e pesquisa no FAQ.

Disco e sistemas de arquivos

Você precisa reconhecer:

disco, partição, sistema de arquivos e ponto de montagem;
nomes como /dev/sda, /dev/vda, /dev/nvme0n1 e suas partições;
GPT versus MBR;
BIOS legado versus UEFI;
ext4, swap, UUID e /etc/fstab;
diferença entre montar um volume e apenas criar seu diretório;
risco destrutivo de fdisk, parted, mkfs, wipefs e grub-install.

Uma confusão entre o disco virtual do laboratório e o disco do hospedeiro pode apagar dados. Este é o principal motivo para a recomendação de uma VM com disco descartável.

Compilação básica

Reconheça o fluxo típico:

código-fonte → configuração → compilação → testes → instalação
                ./configure      make      make check   make install

Nem todos os pacotes usam exatamente esse sistema. O livro fornece as opções corretas para cada um. Você deve entender que:

configure descobre características e cria Makefiles;
o compilador transforma fontes em objetos;
o linker combina objetos e bibliotecas em executáveis;
make executa regras e pode paralelizar tarefas;
make check ou equivalente executa testes;
make install grava arquivos no destino e, portanto, é a fase de maior risco quando o destino está errado;
variáveis como CC, PATH, LFS_TGT e opções --prefix, --host, --build ou DESTDIR mudam qual compilador é usado e onde o resultado é instalado.

Conceitos que precisam estar claros

Conceito	Significado prático no LFS
Hospedeiro	Linux já funcional usado para iniciar a construção.
Alvo	O novo sistema LFS que está sendo criado.
`$LFS`	Caminho raiz do alvo enquanto ele ainda é acessado pelo hospedeiro, normalmente `/mnt/lfs`.
Toolchain	Compilador, assembler, linker, libc, headers e ferramentas que produzem os binários.
Triplet de alvo	Identificador como `x86_64-lfs-linux-gnu`, usado para selecionar as ferramentas do alvo.
Cross-toolchain	Ferramentas executadas no hospedeiro, mas configuradas para produzir o sistema alvo.
Sysroot/DESTDIR	Técnicas para fazer a instalação cair na árvore do alvo e não no hospedeiro.
`chroot`	Troca a raiz visível do processo para `$LFS`; não é uma máquina virtual nem uma barreira de segurança.
Bibliotecas dinâmicas	Arquivos carregados em tempo de execução; caminho ou ABI errados impedem um binário de iniciar.
FHS	Convenções da hierarquia de diretórios, como `/usr`, `/etc`, `/var` e `/home`.
Init	Primeiro processo do espaço de usuário; nesta edição, systemd.
Bootloader	Programa que localiza e carrega o kernel; o fluxo principal do livro usa GRUB.
Firmware	Código externo necessário por certos dispositivos; normalmente é tratado depois no BLFS.

O que não é necessário dominar previamente

Você não precisa escrever um kernel, desenvolver drivers, conhecer assembly profundamente ou programar em C com fluência. Porém, deve estar disposto a pesquisar termos e compreender por que cada fase existe. Copiar comandos sem saber em qual contexto eles atuam é a receita mais comum para contaminar o hospedeiro.

3. Escolhas recomendadas para a primeira construção

Arquitetura

O livro tem como alvos principais x86 e x86-64. Para um desktop ou servidor atual, use x86-64 puro. O resultado padrão não executa binários de 32 bits; multilib é um projeto avançado e não deve ser acrescentado no primeiro LFS. ARM e outras arquiteturas exigem adaptações fora do caminho principal.

Systemd ou SysV

Use a edição estável com systemd. A página oficial informa que a edição SysV anterior não é mais mantida. Misturar instruções dos dois modelos quebra a configuração de inicialização e serviços.

Máquina virtual ou hardware real

Ambiente	Vantagens	Limitações	Veredito inicial
VM	Snapshots, disco descartável, hardware previsível, console fácil	Compilação um pouco mais lenta; acesso físico limitado	Melhor escolha
PC secundário	Aprende firmware e drivers reais	Maior risco de boot e particionamento; recuperação trabalhosa	Depois da VM
PC principal	Desempenho máximo	Risco real aos dados e ao boot existente	Evite na primeira vez
Container	Rápido para experimentar toolchain	Não representa bem kernel, bootloader e boot real	Não serve para a experiência completa

Firmware de boot

Para reduzir variáveis, configure a primeira VM com BIOS legado. O LFS principal ensina GRUB nesse fluxo. Em máquinas UEFI, o próprio livro direciona para as instruções de GRUB com UEFI no BLFS. O procedimento do BLFS não fornece Secure Boot pronto; portanto, essa proteção precisa ser desativada para o caminho documentado.

Recursos

Recurso	Mínimo prático	Recomendado para aprender com conforto
CPU	2 núcleos	4 a 8 vCPUs
RAM	4 GB pode funcionar	8 GB; 12–16 GB se houver folga
Disco do LFS	cerca de 30 GB utilizáveis	60–80 GB para fontes, builds, logs e BLFS inicial
Swap	útil com pouca RAM	2–8 GB, conforme o hospedeiro
Internet	necessária para fontes e consulta	conexão estável e downloads verificados

Os quatro núcleos e 8 GB são a recomendação editorial oficial. Os tamanhos de disco acima são margem operacional desta pesquisa, não um mínimo oficial fixo: fontes descompactadas, árvores de compilação, logs, snapshots e pacotes do BLFS consomem espaço rapidamente.

Distribuição hospedeira

Use Debian, Ubuntu, Fedora, openSUSE ou outra distribuição recente na mesma arquitetura do alvo. WSL não é a escolha ideal para a experiência completa porque boot, dispositivos, montagens e kernel têm particularidades. Uma distribuição Linux normal dentro de VirtualBox, VMware, KVM/QEMU ou Hyper-V é mais previsível.

4. O laboratório seguro

Uma topologia simples:

Computador físico
└── Hipervisor
    └── VM Linux hospedeira
        ├── Disco 1: distribuição hospedeira
        └── Disco 2: alvo LFS
            ├── partição raiz ext4
            └── swap opcional

Separar o disco hospedeiro do disco LFS deixa evidente qual dispositivo pode ser formatado. Ainda assim, confira os nomes: uma VM pode apresentar discos como /dev/sda e /dev/sdb, ou /dev/vda e /dev/vdb.

Snapshots recomendados

Hospedeiro pronto: ferramentas instaladas e script de requisitos aprovado.
Disco LFS preparado: partições, sistema de arquivos e fontes validadas.
Toolchain temporária concluída: fim dos capítulos 5 e 6.
Antes do sistema final: ambiente temporário salvo e entrada no chroot conferida.
Antes do GRUB: kernel e configurações prontos, mas bootloader ainda não alterado.
Primeiro boot bem-sucedido: console, rede e armazenamento verificados.

Não tire um snapshot enquanto há gravações intensas sem usar o mecanismo consistente do hipervisor. Desligar a VM antes do snapshot é a opção mais simples.

Proteções básicas

Não compartilhe a raiz do hospedeiro com a VM em modo escrita.
Não exponha serviços do LFS diretamente à internet durante a construção.
Use NAT no laboratório; evite bridge até ter firewall e atualizações planejadas.
Faça backup do diário e de scripts fora do disco LFS.
Nunca execute comandos destrutivos com nomes copiados de exemplos sem substituir e validar os dispositivos.
Antes de mkfs ou grub-install, execute lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL e confira tamanho e modelo.

5. Preparação do hospedeiro

Fixe a edição do livro

Baixe ou mantenha abertas somente as referências da edição estável:

Anote no diário: LFS 13.0-systemd, publicado em 2026-03-05. Se o link stable-systemd passar a apontar para uma edição posterior no meio do trabalho, continue usando a URL versionada da edição 13.0 ou recomece conscientemente com a nova versão. Não migre pela metade.

Instale as ferramentas do hospedeiro

Os nomes variam conforme a distribuição. Em Debian/Ubuntu, um ponto de partida comum é:

sudo apt update
sudo apt install bash binutils bison build-essential coreutils diffutils \
  findutils gawk gcc g++ grep gzip m4 make patch perl python3 sed tar \
  texinfo xz-utils wget

No Fedora, o grupo de desenvolvimento e os pacotes equivalentes fornecem a base:

sudo dnf group install "Development Tools"
sudo dnf install bash bison diffutils findutils gawk gcc gcc-c++ gzip \
  m4 make patch perl python3 sed tar texinfo xz wget

Essas linhas são conveniências, não substituem a verificação oficial. Nomes de pacotes e grupos podem mudar. O critério decisivo é executar o script version-check.sh da seção Host System Requirements e corrigir tudo que ele marcar. O projeto também exige relações específicas: /bin/sh deve conduzir ao Bash, awk ao Gawk e yacc ao Bison ou a um wrapper compatível.

Não altere cegamente links fundamentais de uma distribuição ativa. Se o hospedeiro usa Dash como /bin/sh, a solução conservadora é escolher outra VM hospedeira ou aplicar exatamente o procedimento recomendado para essa distribuição, entendendo o impacto.

Registre o ambiente

Antes de começar, salve:

uname -a
cat /etc/os-release
uname -m
gcc --version
ld --version | head -n1
df -hT
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL

Guarde também a saída integral do script de requisitos. Ao pedir ajuda, o projeto solicita a distribuição hospedeira, o resultado desse script, a seção ou pacote, o erro exato e qualquer desvio em relação ao livro.

6. Disco, partições e montagem

Esquema simples para a primeira VM

No disco exclusivo do LFS, use:

uma partição ext4 para /, ocupando a maior parte do disco;
swap opcional se a RAM for limitada;
nenhuma partição /home separada na primeira tentativa;
no fluxo UEFI, uma ESP FAT32 adicional conforme o BLFS.

Evite LVM, RAID, Btrfs avançado, criptografia e múltiplas partições até dominar o fluxo básico. Esses recursos podem ser adicionados em uma segunda construção.

A regra antes de formatar

Execute e confira:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
findmnt

Só então use a ferramenta de particionamento escolhida. Não há comando genérico seguro para formatar: /dev/sdX é apenas marcador. O dispositivo errado destrói dados. Em uma VM com um segundo disco de tamanho reconhecível, o risco fica muito menor.

Variável e ponto de montagem

O livro usa /mnt/lfs:

export LFS=/mnt/lfs
umask 022
echo "$LFS"
umask

O resultado esperado é /mnt/lfs e 0022 ou 022. Depois de criar o sistema de arquivos no dispositivo correto, monte-o conforme o livro, por exemplo:

sudo mkdir -pv "$LFS"
sudo mount -v -t ext4 /dev/PARTICAO_LFS "$LFS"
findmnt "$LFS"

PARTICAO_LFS precisa ser substituído pelo nome validado. Não cole o exemplo literalmente. A montagem do alvo não deve usar nodev nem nosuid, pois isso interfere em fases posteriores.

A verificação de quatro linhas

Crie o hábito de rodar isto ao retomar o trabalho:

whoami
pwd
printf 'LFS=%s\n' "$LFS"
findmnt "$LFS"

Essa verificação simples evita instalar no lugar errado, trabalhar como usuário incorreto ou continuar com a partição desmontada.

7. Fontes, patches e integridade

Crie $LFS/sources com o modo sticky definido pelo livro. Baixe os arquivos usando o wget-list-systemd da mesma edição e confira os hashes com o arquivo md5sums correspondente:

mkdir -v "$LFS/sources"
chmod -v a+wt "$LFS/sources"
wget --input-file=wget-list-systemd --continue --directory-prefix="$LFS/sources"
pushd "$LFS/sources"
md5sum -c md5sums
popd

Todos os itens devem ser encontrados e validados. Um hash divergente pode significar download interrompido, arquivo errado, versão misturada ou corrupção. Não “ignore e tente compilar”.

Antes do download, leia os avisos de segurança. O próprio livro alerta que versões vulneráveis podem ter sido removidas pelos autores e que uma substituição indicada pela equipe LFS pode ser necessária. Use a correção da errata ou do aviso oficial, não uma versão arbitrariamente mais nova.

Regras úteis:

mantenha tarballs e patches na pasta sources;
extraia cada pacote novamente antes de cada passagem;
remova a árvore descompactada depois da etapa, salvo instrução contrária;
não reaproveite uma árvore já configurada para outro passe;
não use cp -R para duplicar fontes: timestamps e links podem ser alterados;
não aplique patches “parecidos” encontrados em blogs sem entender a versão alvo;
depois do download como usuário comum, ajuste os donos conforme o livro para não deixar UIDs sem nome no LFS final.

8. As identidades e ambientes do processo

Grande parte da dificuldade não está nos comandos, mas em saber quem deve executá-los e onde.

Fase	Identidade	Ambiente	Risco principal
Preparar disco e diretórios	`root` no hospedeiro	Hospedeiro, `$LFS` definido	Formatar ou montar o dispositivo errado
Capítulos 5 e 6	usuário `lfs`	Shell limpo, PATH controlado	Usar ferramentas do hospedeiro ou instalar nele
Preparar sistemas virtuais	`root` no hospedeiro	`$LFS` montado	Montagens incompletas ou propagação incorreta
Capítulos 7 a 10	`root` dentro do `chroot`	Raiz do LFS	Confundir o `chroot` com o hospedeiro
Configurar GRUB	`root`, contexto indicado	Disco explicitamente validado	Sobrescrever o bootloader errado

Por que existe o usuário `lfs`

Os capítulos da toolchain são executados como usuário sem privilégios para limitar os danos de um caminho errado. A conta recebe acesso apenas às áreas necessárias e usa arquivos de inicialização que criam um ambiente previsível. Executar esses capítulos como root elimina essa proteção e pode instalar arquivos no hospedeiro.

Por que o ambiente é limpo

Variáveis herdadas, aliases, caminhos adicionais e opções de compilador podem fazer os pacotes encontrarem bibliotecas externas. O livro configura .bash_profile e .bashrc do usuário lfs para usar um ambiente mínimo, PATH definido, locale previsível, LFS_TGT correto e paralelismo controlado.

Não leve para esse shell:

Conda, pyenv, Nix, Homebrew Linux ou SDKs de terceiros;
CFLAGS, CXXFLAGS, LDFLAGS “otimizados”;
aliases para make, rm, cp ou compiladores;
LD_LIBRARY_PATH personalizado;
jobs paralelos exagerados.

`chroot` não é isolamento de segurança

Depois de montar /dev, /proc, /sys e /run, o ambiente LFS compartilha o kernel e dispositivos do hospedeiro. Como root dentro dele, ainda é possível causar dano. O chroot muda a raiz dos caminhos para construir o sistema final em seu próprio contexto; ele não substitui VM, container seguro ou sandbox.

9. Visão completa das etapas do livro

Etapa	Capítulos	Resultado	Checkpoint essencial
Preparação	1–4	Hospedeiro verificado, disco montado, fontes íntegros, usuário `lfs`	Script de requisitos limpo; hashes aprovados
Cross-toolchain	5	Binutils, GCC parcial, headers, Glibc e libstdc++ independentes	Teste do linker e caminhos do alvo corretos
Ferramentas temporárias	6	Shell e ferramentas básicas compiladas para o alvo	Executáveis pertencem ao alvo, não ao host
Entrada no novo sistema	7	Sistemas virtuais montados, `chroot`, estrutura e utilitários adicionais	`/`, PATH e ferramentas apontam para o LFS
Sistema final	8	Toolchain e pacotes finais recompilados nativamente	Testes essenciais sem falhas inesperadas
Configuração	9	Rede, locale, console, relógio e systemd configurados	Arquivos coerentes com a máquina
Boot	10	Kernel, `fstab` e GRUB configurados	Kernel inclui armazenamento e sistema de arquivos raiz
Fechamento	11	Identidade do sistema e reinicialização	Backup/snapshot e plano de recuperação prontos

Por que há múltiplas passagens

No início, o novo sistema não possui compilador nem biblioteca C. O hospedeiro é inevitável. A primeira passagem de Binutils e GCC cria ferramentas orientadas ao alvo; headers do Linux e Glibc formam a primeira base; a libstdc++ permite compilar C++. Depois, ferramentas temporárias são criadas para que o chroot consiga trabalhar. Finalmente, tudo é recompilado nativamente dentro do LFS, quebrando a dependência prática do hospedeiro.

Pular um passe ou reaproveitar diretórios configurados mistura caminhos, ABI e artefatos. Um erro pode aparecer somente muitos pacotes depois, por isso a ordem é parte do projeto.

10. Roteiro detalhado de execução

Fase A — preparação

Leia o prefácio, requisitos, tipografia e estrutura da edição completa.
Crie o diário de construção e registre o hospedeiro.
Prepare uma VM e um disco exclusivo.
Execute o script oficial de versões e resolva todas as pendências.
Particione e formate somente o disco alvo confirmado.
Exporte $LFS=/mnt/lfs, defina umask 022 e monte o alvo.
Crie sources, baixe arquivos e verifique todos os hashes.
Crie o layout inicial, diretório tools, usuário e grupo lfs exatamente como no livro.
Configure o shell limpo do usuário lfs.
Tire um snapshot.

Não prossiga se: $LFS estiver vazio, a partição não estiver montada, houver hash divergente, links do hospedeiro estiverem errados ou o script de requisitos acusar incompatibilidade.

Fase B — cross-toolchain

Construa Binutils Pass 1, GCC Pass 1, Linux API Headers, Glibc e libstdc++ na ordem do capítulo 5. Essa é a fundação mais sensível.

Antes de cada pacote:

whoami          # deve ser lfs
echo "$LFS"     # deve mostrar /mnt/lfs
echo "$LFS_TGT"
echo "$PATH"
pwd             # normalmente dentro de $LFS/sources ou árvore recém-extraída

Depois da Glibc, o livro faz testes de sanidade para confirmar o interpretador dinâmico e a pesquisa de includes. Não aceite um resultado “quase igual”: caminhos contendo diretórios inesperados do hospedeiro indicam contaminação.

Checkpoint: guarde o log de cada configure, compilação e teste; registre o tempo da primeira passagem de Binutils, usado como unidade SBU.

Fase C — ferramentas temporárias

No capítulo 6, compile M4, Ncurses, Bash, Coreutils, Diffutils, File, Findutils, Gawk, Grep, Gzip, Make, Patch, Sed, Tar, Xz e as segundas passagens de Binutils e GCC, seguindo a lista exata da edição.

O uso de DESTDIR=$LFS, --host=$LFS_TGT e opções semelhantes é deliberado. Não remova essas partes por parecerem redundantes. Elas fazem o software ser produzido e instalado para o alvo.

Checkpoint: ao terminar, tire snapshot ou faça a cópia recomendada pelo capítulo de limpeza e salvamento. Essa base permite recuperar uma construção sem recompilar tudo, desde que restauração, montagens e donos sejam feitos corretamente.

Fase D — sistemas virtuais e `chroot`

De volta ao root do hospedeiro:

confirme $LFS e a montagem principal;
mude a propriedade conforme a seção correta;
prepare /dev;
monte /proc, /sys, /run e os demais sistemas virtuais como indicado;
entre no chroot com ambiente explicitamente controlado.

Após entrar, valide:

pwd
echo "$PATH"
ls /
mount

Dentro do chroot, / é o sistema LFS. $LFS deixa de ser necessário. Crie diretórios, links e arquivos essenciais; depois compile as ferramentas adicionais temporárias do capítulo 7.

Se desligar e retomar, as montagens virtuais precisam ser refeitas antes de entrar novamente. A seção oficial Building LFS in Stages detalha o que restaurar em cada faixa de capítulos.

Fase E — sistema final

No capítulo 8, compile as versões finais de todos os componentes. Leia o início do capítulo sobre gerenciamento de pacotes antes de instalar dezenas de pacotes: LFS não escolhe um método por você.

Para cada pacote:

extraia um tarball limpo;
entre no diretório criado;
aplique apenas os patches indicados;
configure exatamente como a edição manda;
compile;
execute a suíte de testes indicada;
classifique qualquer falha consultando notas e logs oficiais;
instale;
salve o log e remova a árvore de build.

Não use flags agressivas como -march=native, LTO ou otimizações copiadas do Gentoo na primeira construção. Primeiro obtenha um sistema reproduzível conforme a referência; personalize em uma segunda passagem.

Fase F — configuração do sistema

O capítulo 9 transforma arquivos compilados em um sistema coerente. Você configurará:

interface e método de rede;
hostname e /etc/hosts;
regras e nomes de dispositivos;
relógio do hardware e fuso horário;
locale e codificação;
console e mapa de teclado;
comportamento do systemd;
arquivos e serviços necessários ao boot.

Para português brasileiro, selecione uma locale UTF-8 efetivamente gerada e suportada, normalmente pt_BR.UTF-8. Não confunda locale de mensagens com layout do teclado. O mapa de console vale para o terminal virtual; um futuro KDE terá configuração própria.

Use hostname simples, em minúsculas e sem espaços. Em laboratório, evite nomes que colidam com máquinas reais.

Fase G — kernel e boot

O kernel precisa conter, embutidos ou disponíveis no momento certo:

controlador do disco virtual ou físico;
suporte ao sistema de arquivos da raiz;
suporte a /dev, devtmpfs e pseudo-terminais;
driver de console;
rede necessária;
opções requeridas pelo systemd;
firmware, quando o driver não funciona sem ele.

Para a primeira VM, é mais simples compilar diretamente no kernel (Y) os drivers do controlador de armazenamento e do ext4. Se esses itens forem módulos (M) e você não tiver um initramfs correto, o kernel não encontrará a raiz e cairá em panic.

Use como ponto de partida a configuração do kernel hospedeiro somente se souber revisá-la; ela pode incluir recursos desnecessários ou depender de initramfs. Outra opção é make defconfig e ativar conscientemente o hardware apresentado pela VM. Salve o .config fora da árvore de build.

Crie o /etc/fstab usando UUIDs quando possível e confira-os com blkid. Um erro no dispositivo raiz, tipo do sistema de arquivos ou opções de montagem impede o boot.

GRUB e o risco real

No BIOS, siga o capítulo 10 da edição estável. A instalação do GRUB escreve no disco; valide novamente com lsblk. Em dual boot ou hardware real, não presuma que o livro preservará automaticamente a configuração existente.

No UEFI, não aplique o fluxo BIOS: instale as dependências e siga o procedimento específico do BLFS. Tenha uma mídia de recuperação e backup da partição EFI.

Antes de reiniciar:

confirme que o arquivo do kernel está em /boot;
confirme o nome usado em grub.cfg;
confira UUID ou dispositivo da raiz;
confira /etc/fstab;
verifique se o driver do disco e o ext4 estão disponíveis sem depender de algo ausente;
defina a senha de root;
tire snapshot.

11. Testes e critérios para avançar

Uma enxurrada de warnings durante compilação pode ser normal; uma falha de teste precisa ser classificada. O livro afirma que testes de Binutils, GCC e Glibc têm importância especial. Algumas falhas são conhecidas e dependem do ambiente, por isso compare o resultado com os logs oficiais da edição 13.0.

Classificação prática

Resultado	Ação
Todos os testes passam	Registre e continue.
Falha explicitamente descrita como esperada no livro/log oficial	Registre a correspondência e continue quando autorizado.
Falha por falta de PTY, permissão ou montagem	Corrija o ambiente e repita; não trate como defeito do pacote.
Falha no toolchain sem correspondência oficial	Pare; procure contaminação, versão, patch, ambiente e paralelismo.
Comando de compilação termina com erro	Preserve log, descubra o primeiro erro real, limpe e reconstrua.
Apenas warnings	Leia o contexto; warnings comuns não equivalem a falha.

Paralelismo

O livro estima tempos em SBUs, medidos relativamente à primeira compilação de Binutils. Paralelismo acelera o processo, mas pode embaralhar logs, aumentar RAM consumida e expor dependências incorretas.

Comece com algo conservador, como quatro jobs quando houver quatro vCPUs e 8 GB. Use a forma indicada na edição para definir MAKEFLAGS. Se uma compilação falhar de maneira obscura, limpe a árvore e repita com -j1; não apenas rode make novamente em uma árvore parcialmente construída.

Regra de reconstrução limpa

Quando houver dúvida:

salve o log com erro;
volte a $LFS/sources;
remova o diretório descompactado daquele pacote;
extraia o tarball original novamente;
confirme usuário e ambiente;
repita os comandos exatos do livro.

Essa abordagem é mais lenta por minutos e economiza horas de investigação de uma árvore contaminada.

12. Como pausar e retomar sem quebrar tudo

O LFS pode ser construído em várias sessões, embora o livro modele uma sessão contínua. Depois de reiniciar o hospedeiro:

Se estiver nos capítulos 1 a 4

monte a partição LFS;
exporte $LFS também no shell de root quando necessário;
defina umask 022;
confirme diretórios e donos.

Se estiver nos capítulos 5 e 6

monte $LFS;
use su - lfs para obter o shell limpo;
confirme $LFS, $LFS_TGT, PATH e whoami;
retome apenas em um pacote com árvore limpa.

Se estiver nos capítulos 7 a 10

monte $LFS;
exporte $LFS como root no hospedeiro;
refaça as montagens de /dev, /proc, /sys e /run conforme o capítulo 7;
entre novamente no chroot com o comando completo do livro;
confira o contexto antes de continuar.

Nunca dependa da memória. Mantenha um arquivo STATUS.md fora da raiz LFS com último capítulo, último pacote concluído, usuário esperado, snapshot atual, falhas aceitas e próxima ação.

13. Diário e rastreabilidade

Um registro mínimo por pacote:

Data/hora:
Livro e seção:
Pacote e versão:
Usuário/contexto: host root | lfs | chroot root
Diretório de trabalho:
Comandos copiados da edição:
MAKEFLAGS:
Resultado da compilação:
Resultado dos testes:
Falhas esperadas comparadas com:
Arquivos ou configurações alterados:
Desvios do livro:
Próximo passo:

Para capturar uma sessão interativa, script pode gerar um log, mas revise-o para não registrar senhas ou informações sensíveis:

script -a ~/lfs-build.log

Não cole senha em comandos e não compartilhe logs sem revisar hostname, caminhos pessoais, IPs, tokens e chaves.

14. Erros comuns e como diagnosticá-los

Sintoma	Causa provável	Verificação e correção
Arquivos aparecem no hospedeiro	`$LFS` vazio, `DESTDIR` ausente ou comando como `root` fora do contexto	Pare, confira histórico e arquivos instalados; restaure snapshot se houver contaminação.
Compilador encontra headers do host	PATH ou opções de toolchain incorretas	Repita os testes de sanidade e reconstrua a partir de árvore limpa.
`configure: C compiler cannot create executables`	Linker, libc, alvo ou espaço em disco	Leia `config.log`; confira interpretador, permissões e `df -h`.
Muitos testes falham por PTY	`/dev/pts` ou sistemas virtuais incorretos	Refaça as montagens conforme o capítulo 7 e consulte o FAQ.
`chroot: failed to run command /usr/bin/env`	Ferramenta temporária ou linker ausente	Volte ao checkpoint anterior; valide os capítulos 5 e 6.
`No such file or directory` em binário existente	Interpretador dinâmico inexistente ou arquitetura errada	Use `file` e `readelf -l`; confirme o caminho do loader.
Kernel panic: unable to mount root fs	Driver de armazenamento/fs ausente, parâmetro `root=` errado ou falta de initramfs	Recompile com drivers essenciais embutidos e confira GRUB/UUID.
GRUB inicia, mas não encontra kernel	Caminho ou nome incorreto em `grub.cfg`	Liste `/boot`, edite a entrada e mantenha mídia de recuperação.
Rede não sobe	interface, driver, firmware ou unidade systemd incorretos	Confira `ip link`, logs do kernel e configuração da edição.
Compilação morre aleatoriamente	Falta de RAM, OOM, temperatura, armazenamento ou paralelismo excessivo	Veja logs do kernel, reduza `-j`, ative swap e teste hardware.
Pacote seguinte falha após uma instalação “aceita”	Erro anterior ignorado ou árvore reaproveitada	Volte ao último checkpoint confiável; não empilhe correções casuais.
Permissões estranhas	`umask`, dono ou usuário incorreto	Compare com o livro; corrija somente os caminhos afetados.

Como encontrar o primeiro erro real

O final de um log costuma mostrar apenas make: *** Error 2. Pesquise para cima por error:, fatal:, undefined reference, No such file, cannot ou pelo primeiro teste que falhou. Mensagens posteriores podem ser apenas consequências.

Ao pedir ajuda, informe:

versão exata do livro;
distribuição e versão do hospedeiro;
arquitetura;
saída do script de requisitos;
capítulo, pacote e passe;
comando executado;
primeiro erro e contexto anterior;
desvios realizados;
resultado ao repetir com árvore limpa e -j1.

Consulte primeiro o FAQ do LFS e as listas de discussão.

15. Gerenciamento de pacotes: a decisão que o LFS deixa para você

LFS e BLFS não impõem um gerenciador porque isso desviaria o objetivo educativo e nenhuma técnica atende todos os usuários. Porém, instalar tudo sem registro torna atualizações e remoções difíceis.

Alternativas

Método	Vantagem	Limitação
Diário manual	Zero complexidade	Não sabe quais arquivos pertencem a cada pacote
Manifesto antes/depois	Registra arquivos novos	Pode confundir arquivos temporários e mudanças simultâneas
`DESTDIR` + pacote tar	Produz artefato reinstalável	Nem todo pacote aceita staging sem ajustes
Monitor de instalação	Captura mudanças no sistema	Pode perder scripts ou alterações indiretas
Diretórios separados em `/opt`	Rollback simples para alguns apps	Não funciona bem para componentes centrais e escala mal
Gerenciador próprio ou adaptado	Atualizações e consultas estruturadas	Grande projeto adicional; dependências são complexas
Reconstrução integral	Estado reproduzível quando automatizado	Custo de tempo e necessidade de scripts muito bem mantidos

Para a primeira construção, adote pelo menos:

inventário com pacote, versão, URL, hash e data;
log de configuração, testes e instalação;
lista das alterações manuais em /etc;
backup antes de atualizar Glibc, GCC, Binutils, systemd ou kernel;
política clara: atualizar pontualmente ou reconstruir uma nova raiz.

Não tente implantar APT ou DNF no meio do primeiro LFS. Concluir o sistema conforme o livro e só então estudar uma técnica de pacotes preserva o objetivo da experiência.

16. Primeiro boot: lista de verificação

No primeiro boot, mantenha o console do hipervisor aberto. Não dependa de SSH.

O mínimo que deve funcionar

uname -a
cat /etc/os-release
systemctl --failed
systemctl status
mount
findmnt
df -hT
free -h
ip link
ip addr
journalctl -b -p warning

Confirme:

kernel e arquitetura esperados;
raiz montada no dispositivo correto e em leitura/escrita;
/proc, /sys, /dev e /run presentes;
relógio, fuso e locale;
hostname;
nenhuma unidade essencial falhou;
interface de rede aparece;
console e teclado funcionam;
reinicialização e desligamento funcionam;
o sistema inicia novamente sem o disco/ISO hospedeiro.

Se não iniciar

Não reinstale tudo imediatamente. Use a mídia hospedeira:

inicialize a distribuição de resgate;
monte a raiz LFS em /mnt/lfs;
monte os sistemas virtuais;
entre no chroot;
corrija kernel, fstab ou GRUB;
saia, desmonte em ordem inversa e tente novamente.

O snapshot anterior ao boot é uma proteção adicional, não substituto para entender a falha.

17. O que fazer imediatamente depois do LFS

Um sistema que inicia ainda não está pronto para uso cotidiano nem para internet. A sequência conservadora no BLFS é:

Prioridade 1 — recuperação e confiança

criar usuário pessoal não-root;
instalar e configurar sudo se desejado;
configurar certificados de autoridades confiáveis com make-ca;
instalar firmware necessário;
configurar rede e resolução DNS de forma persistente;
instalar editor alternativo e ferramentas de diagnóstico;
estabelecer backup e método de recuperação.

Prioridade 2 — segurança

ler os avisos de segurança do LFS e BLFS;
instalar PAM e política de senhas se o perfil exigir;
configurar firewall antes de expor interfaces;
instalar OpenSSH somente se necessário, desabilitando login remoto de root e autenticação por senha quando possível;
sincronizar hora;
planejar atualizações de kernel e bibliotecas;
revisar serviços habilitados.

Prioridade 3 — usabilidade

compressão, certificados, curl e ferramentas de download;
sistema de som e vídeo;
Xorg ou Wayland e drivers gráficos;
KDE Plasma, se o objetivo for desktop;
fontes, navegador e aplicações;
impressão, Bluetooth e Wi-Fi conforme o hardware.

Não instale um desktop inteiro antes de resolver certificados, rede, usuários, firmware, logs e atualização. Uma GUI pode esconder uma base insegura ou difícil de recuperar.

18. Segurança e manutenção contínua

Em Debian ou Fedora, mantenedores transformam patches em pacotes e distribuem atualizações. No LFS, essa responsabilidade é sua. O capítulo final lembra que novos bugs e avisos aparecem regularmente e que o proprietário precisa acompanhá-los.

Rotina mínima

Semanalmente:

consulte LFS/BLFS Security Advisories;
monitore projetos críticos usados no sistema;
verifique falhas de serviço e logs anormais;
confirme backups.

Mensalmente:

inventarie versões instaladas;
priorize kernel, Glibc, OpenSSL/GnuTLS, systemd, OpenSSH, navegador e serviços expostos;
teste restauração em VM;
reconstrua pacotes atualizados em ambiente controlado;
mantenha kernel anterior e entrada de boot de recuperação.

A cada nova edição LFS:

leia changelog e errata;
decida entre atualização pontual e nova raiz;
nunca misture instruções novas no meio de uma build antiga;
para sistemas importantes, prefira construir em partição ou VM paralela e migrar depois dos testes.

O que não fazer em produção

expor um LFS recém-instalado diretamente à internet;
assumir que a versão do livro continua segura meses depois;
atualizar Glibc ou systemd sem backup e plano de rollback;
compilar como root fora do contexto indicado;
adicionar repositórios binários de outra distribuição;
confiar apenas na versão exibida, sem acompanhar patches de segurança;
apagar o kernel anterior antes de validar o novo.

19. Tempo necessário e estratégia de estudo

O tempo varia com CPU, disco, paralelismo, testes e quantidade de erros. SBU é uma medida relativa: se Binutils Pass 1 levou dez minutos e outro pacote está estimado em 4,5 SBU, espere aproximadamente 45 minutos sob condições semelhantes. Não trate isso como garantia.

Para quem já administra Linux, uma expectativa realista é:

Atividade	Faixa prática
Leitura e laboratório	3–6 horas
Preparação e downloads	1–3 horas
Toolchain e temporários	4–12 horas
Sistema final e testes	8–30 horas
Kernel, configuração e primeiro boot	2–8 horas
Correções e diário	variável

Espalhar o trabalho por vários dias é normal. O objetivo não é bater recorde, e sim conseguir explicar por que o sistema inicia.

Plano de aprendizagem antes da construção

Em uma VM descartável, crie e monte uma partição ext4.
Compile um programa C pequeno e examine-o com file, ldd e readelf.
Baixe, verifique, extraia, configure, compile, teste e instale um pacote simples em um prefixo dentro de $HOME.
Crie um chroot de teste com uma ferramenta como debootstrap apenas para compreender o conceito — sem confundi-lo com LFS.
Configure e compile um kernel para a VM hospedeira, mantendo o kernel anterior.
Leia os capítulos 1 a 5 do LFS antes de executar o primeiro comando da toolchain.

20. Checklist mestre

Antes de começar

Escolhi LFS pelo aprendizado, não como atalho para produção.
Fixei a edição LFS 13.0-systemd e abri errata e avisos.
Uso VM x86-64 e disco alvo separado.
Tenho snapshot e espaço suficiente.
Sei distinguir BIOS de UEFI.
Executei o script oficial de requisitos sem pendências.
Registrei hospedeiro, arquitetura e versões.

Antes da toolchain

$LFS contém o caminho correto.
umask é 022.
A partição está montada sem nodev/nosuid.
Todos os hashes foram aprovados.
Usuário lfs e ambiente limpo estão corretos.
Nenhuma flag personalizada de compilação vazou para o shell.

Antes do `chroot`

Capítulos 5 e 6 terminaram sem erro não explicado.
Toolchain passou nos testes de sanidade.
Tenho logs e checkpoint restaurável.
/dev, /proc, /sys e /run foram montados conforme o livro.
Entendo que o chroot compartilha o kernel do hospedeiro.

Antes do primeiro boot

Kernel tem drivers do disco e da raiz disponíveis no boot.
/etc/fstab aponta para volumes corretos.
GRUB aponta para kernel e raiz corretos.
Senha de root foi definida.
Hostname, locale, fuso e rede foram configurados.
Tenho console, snapshot e mídia de recuperação.
O disco de boot correto foi escolhido no hipervisor.

Depois do boot

Nenhuma unidade essencial falhou.
Armazenamento e sistemas virtuais estão corretos.
Logs do boot foram revisados.
Criei usuário não-root.
Planejei certificados, firewall, firmware e atualizações via BLFS.
Registrei a construção e preservei fontes, hashes e configuração do kernel.

Recomendações práticas

Para a primeira construção, use esta combinação: VM x86-64, BIOS legado, LFS 13.0-systemd, ext4, uma partição raiz, quatro vCPUs, 8 GB de RAM e 60–80 GB de disco. Siga o livro literalmente, registre cada etapa e mantenha snapshots nos marcos principais.

Não automatize a primeira tentativa. Digitar, ler e compreender os comandos é parte do valor do LFS. Na segunda construção, transforme seu diário em scripts pequenos e reiniciáveis, um capítulo por vez, sempre falhando imediatamente quando um comando retorna erro. Automação sem compreensão apenas reproduz erros mais rápido.

Ao encontrar um problema, resista à vontade de instalar uma versão mais nova ou buscar uma linha aleatória em um fórum. Verifique, nesta ordem: usuário atual, $LFS, montagem, PATH, versão do livro, hash da fonte, árvore limpa, errata, logs oficiais e FAQ. Grande parte das falhas nasce de contexto incorreto, não de um bug inédito.

Se o objetivo final for KDE Plasma, trate-o como uma segunda fase longa no BLFS. Primeiro conclua um LFS de console que inicializa repetidamente, possui rede, certificados, usuário comum, segurança básica e recuperação. Só depois avance para firmware gráfico, Mesa, Wayland/Xorg, áudio e Plasma.

Conclusão

O mínimo para construir LFS não é decorar comandos: é compreender os limites entre hospedeiro e alvo, preservar um ambiente de compilação controlado, respeitar a ordem da toolchain, validar testes e assumir a manutenção que uma distribuição normalmente faria por você.

Uma construção bem-sucedida deve produzir mais que um prompt de login. Você deve sair dela capaz de explicar como o primeiro compilador nasce, por que a Glibc é central, como o sistema se torna independente do hospedeiro, o que o chroot faz, por que o kernel precisa de certos drivers no boot e como o GRUB encontra a raiz. Se essas relações ficaram claras, o LFS cumpriu seu propósito.

O procedimento recomendado é simples em conceito: laboratório descartável, edição estável fixa, comandos oficiais, checkpoints frequentes, logs completos e nenhuma personalização prematura. Depois do primeiro boot, BLFS, segurança e política de atualizações deixam de ser opcionais se a máquina for realmente utilizada.

Fontes consultadas

Nota sobre atualidade

Pesquisa concluída em 21 de julho de 2026. A edição estável identificada foi o LFS 13.0-systemd, publicada em 5 de março de 2026. Pacotes, erratas e vulnerabilidades mudam depois da publicação; antes de iniciar ou retomar uma construção, confirme a edição estável, a errata e os avisos de segurança nos sites oficiais. Nunca altere a edição no meio da mesma construção sem reiniciar ou auditar integralmente as diferenças.