--- title: "Linux From Scratch: conhecimento mínimo e roteiro completo para construir seu próprio Linux" date: 2026-07-21 summary: "Guia prático e aprofundado sobre o que aprender, preparar, construir, validar e manter ao criar um sistema Linux From Scratch." tags: [pesquisa, linux, linux-from-scratch, lfs, compilacao, administracao-de-sistemas] flowerColor: "#72d6c9" --- # 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](https://www.linuxfromscratch.org/lfs/view/stable-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)](https://www.linuxfromscratch.org/blfs/view/stable-systemd/). **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](https://www.linuxfromscratch.org/advisories/) 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: 1. **Use uma única versão estável do livro do começo ao fim.** Não reutilize scripts ou comandos de outra edição. 2. **Entenda em qual contexto cada comando roda:** usuário normal, `root` no hospedeiro, usuário `lfs`, ou `root` dentro do `chroot`. 3. **Confira sempre `$LFS`, ponto de montagem, usuário atual e diretório atual** antes de comandos de instalação ou remoção. 4. **Não pule testes importantes**, principalmente de Binutils, GCC e Glibc; compare falhas esperadas com os logs oficiais. 5. **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](https://www.linuxfromscratch.org/lfs/view/stable-systemd/), do [PDF oficial da mesma edição](https://www.linuxfromscratch.org/lfs/downloads/stable-systemd/LFS-BOOK-13.0-SYSD.pdf), 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](https://www.linuxfromscratch.org/blfs/) 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: ```text 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](https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/grub-setup.html). 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: ```text 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 1. **Hospedeiro pronto:** ferramentas instaladas e script de requisitos aprovado. 2. **Disco LFS preparado:** partições, sistema de arquivos e fontes validadas. 3. **Toolchain temporária concluída:** fim dos capítulos 5 e 6. 4. **Antes do sistema final:** ambiente temporário salvo e entrada no `chroot` conferida. 5. **Antes do GRUB:** kernel e configurações prontos, mas bootloader ainda não alterado. 6. **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: - [livro estável em HTML](https://www.linuxfromscratch.org/lfs/view/stable-systemd/); - [livro LFS 13.0-systemd em PDF](https://www.linuxfromscratch.org/lfs/downloads/stable-systemd/LFS-BOOK-13.0-SYSD.pdf); - [diretório oficial de downloads da edição](https://www.linuxfromscratch.org/lfs/downloads/stable-systemd/); - [errata da edição 13.0](https://www.linuxfromscratch.org/lfs/errata/13.0-systemd/); - [avisos de segurança atuais](https://www.linuxfromscratch.org/advisories/). 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 é: ```bash 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: ```bash 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](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter02/hostreqs.html) 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: ```bash 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: ```bash 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`: ```bash 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: ```bash 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: ```bash 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: ```bash 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 1. Leia o prefácio, requisitos, tipografia e estrutura da edição completa. 2. Crie o diário de construção e registre o hospedeiro. 3. Prepare uma VM e um disco exclusivo. 4. Execute o script oficial de versões e resolva todas as pendências. 5. Particione e formate somente o disco alvo confirmado. 6. Exporte `$LFS=/mnt/lfs`, defina `umask 022` e monte o alvo. 7. Crie `sources`, baixe arquivos e verifique todos os hashes. 8. Crie o layout inicial, diretório `tools`, usuário e grupo `lfs` exatamente como no livro. 9. Configure o shell limpo do usuário `lfs`. 10. 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: ```bash 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: 1. confirme `$LFS` e a montagem principal; 2. mude a propriedade conforme a seção correta; 3. prepare `/dev`; 4. monte `/proc`, `/sys`, `/run` e os demais sistemas virtuais como indicado; 5. entre no `chroot` com ambiente explicitamente controlado. Após entrar, valide: ```bash 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](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter02/stages.html) 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: 1. extraia um tarball limpo; 2. entre no diretório criado; 3. aplique apenas os patches indicados; 4. configure exatamente como a edição manda; 5. compile; 6. execute a suíte de testes indicada; 7. classifique qualquer falha consultando notas e logs oficiais; 8. instale; 9. 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](https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/grub-setup.html). 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](https://www.linuxfromscratch.org/lfs/build-logs/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: 1. salve o log com erro; 2. volte a `$LFS/sources`; 3. remova o diretório descompactado daquele pacote; 4. extraia o tarball original novamente; 5. confirme usuário e ambiente; 6. 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: ```text 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: ```bash 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](https://www.linuxfromscratch.org/lfs/faq.html) e as [listas de discussão](https://www.linuxfromscratch.org/mail.html). ## 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 ```bash 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: 1. inicialize a distribuição de resgate; 2. monte a raiz LFS em `/mnt/lfs`; 3. monte os sistemas virtuais; 4. entre no `chroot`; 5. corrija kernel, `fstab` ou GRUB; 6. 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](https://www.linuxfromscratch.org/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 1. Em uma VM descartável, crie e monte uma partição ext4. 2. Compile um programa C pequeno e examine-o com `file`, `ldd` e `readelf`. 3. Baixe, verifique, extraia, configure, compile, teste e instale um pacote simples em um prefixo dentro de `$HOME`. 4. Crie um `chroot` de teste com uma ferramenta como debootstrap apenas para compreender o conceito — sem confundi-lo com LFS. 5. Configure e compile um kernel para a VM hospedeira, mantendo o kernel anterior. 6. 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 - [Linux From Scratch 13.0-systemd — livro estável em HTML](https://www.linuxfromscratch.org/lfs/view/stable-systemd/) - [Linux From Scratch 13.0-systemd — PDF oficial](https://www.linuxfromscratch.org/lfs/downloads/stable-systemd/LFS-BOOK-13.0-SYSD.pdf) - [Página oficial para leitura do LFS](https://www.linuxfromscratch.org/lfs/read.html) - [Página oficial de downloads do LFS](https://www.linuxfromscratch.org/lfs/download.html) - [Requisitos do sistema hospedeiro](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter02/hostreqs.html) - [Construindo o LFS em etapas e retomando sessões](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter02/stages.html) - [Configuração da variável LFS e umask](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter02/aboutlfs.html) - [Montagem da partição LFS](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter02/mounting.html) - [Pacotes e patches da edição estável](https://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter03/introduction.html) - [Toolchain e ferramentas temporárias](https://www.linuxfromscratch.org/lfs/view/stable-systemd/part3.html) - [Logs oficiais de compilação e testes do LFS 13.0](https://www.linuxfromscratch.org/lfs/build-logs/13.0/) - [Errata do LFS 13.0-systemd](https://www.linuxfromscratch.org/lfs/errata/13.0-systemd/) - [Avisos de segurança atuais do LFS e BLFS](https://www.linuxfromscratch.org/advisories/) - [FAQ oficial do Linux From Scratch](https://www.linuxfromscratch.org/lfs/faq.html) - [Listas de discussão do projeto](https://www.linuxfromscratch.org/mail.html) - [LFS Hints](https://www.linuxfromscratch.org/hints/) - [Beyond Linux From Scratch 13.0-systemd](https://www.linuxfromscratch.org/blfs/view/stable-systemd/) - [Configuração do GRUB para UEFI no BLFS](https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/grub-setup.html) - [Segurança no BLFS](https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/security.html) - [Firewall no BLFS](https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/firewall.html) - [Firmware no BLFS](https://www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/firmware.html) --- ### 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.