Em uma das maiores limpezas de código legado em anos, uma massiva série de 62 patches foi enviada para remover completamente o suporte ao initrd clássico (initial RAM disk) do kernel Linux. Assinada por Askar Safin, a proposta consolida um processo iniciado anos atrás — a depreciação do initrd em 2020 — e sela a modernização do boot com o initramfs como único caminho suportado. O patchset é amplo, toca praticamente todas as arquiteturas mantidas e foi submetido contra a árvore v6.17-rc5, apontando sua rota natural para a janela de merge do Linux 6.18. Para quem quiser ler a proposta na íntegra, vale conferir o tópico “[initrd: remove classic initrd support]” no arquivo público da LKML (lore.kernel.org).
Aposentando uma relíquia: a diferença entre initrd e initramfs
Por que isso importa? Porque initrd e initramfs resolvem o mesmo problema — oferecer um early userspace capaz de montar a raiz real do sistema —, mas o fazem com paradigmas muito diferentes.
O initrd clássico funcionava como um pequeno “disco” na memória (ramdisk). Na prática, era uma imagem de filesystem (comum ver ext2) que o kernel precisava entender e montar. Isso exigia drivers de filesystem embutidos logo no início do boot e uma sequência de passos mais rígida: carregar o ramdisk, montar o FS desse disco, executar o linuxrc//init, fazer pivot_root e, só então, ir para o sistema real. É como iniciar um carro antigo que precisa de vários truques antes de pegar no tranco — funciona, mas é cheio de arestas.
O initramfs, por sua vez, é elegantemente simples: um arquivo cpio compactado que o kernel descompacta direto na memória (ramfs/tmpfs), sem depender de drivers de filesystem específicos. O conteúdo cai numa árvore de diretórios pronta para uso e o /init é executado imediatamente. Menos camadas, menos acoplamento, menos chance de quebra. O resultado prático? Inicialização mais rápida, mais flexível e com um kernel menos inchado. Em termos modernos, o initramfs elimina a “tradução” intermediária do initrd e fala direto a língua do kernel.
Uma limpeza massiva em 62 patches
O trabalho proposto por Safin não é só apagar código antigo; é alinhar a terminologia, os build flags e a documentação para o mundo pós-initrd. O patch 00/62 já estabelece o tom: initrd sai de cena; initramfs segue como primeira classe; o driver de ramdisk (brd) continua existindo — afinal, ainda é útil em outros contextos.
Na prática, isso se traduz em mudanças que afetaram praticamente todo o kernel:
- remoção de caminhos de código do initrd em subsistemas centrais e, principalmente, por toda a pasta
arch/. Safin relata testes em oito arquiteturas diferentes via QEMU, o que dá a dimensão de como o initrd estava entranhado no kernel — de x86 e ARM a SH e SPARC. - renomeação de símbolos e opções de configuração para refletir o estado atual do mundo:
CONFIG_BLK_DEV_INITRDviraCONFIG_INITRAMFS, e todas as antigasCONFIG_RD_*passam aCONFIG_INITRAMFS_DECOMPRESS_*(ex.:CONFIG_RD_GZIP→CONFIG_INITRAMFS_DECOMPRESS_GZIP). É uma mudança grande? Sim. Mas saudável: nomes importam, e manter “INITRD” em flags que já não representam o initrd só confunde e perpetua o passado. - limpeza de parâmetros de boot obsoletos ligados ao initrd clássico:
load_ramdisk,prompt_ramdiskenoinitrddesaparecem;ramdisk_start, usado especificamente pelo initrd, também sai. O objetivo é acabar com switches que não fazem mais sentido e que, em alguns casos, já não tinham efeito real há anos. - atualização de documentação e exemplos para remover menções a rotas antigas (como o pivot_root específico do initrd) e apontar o initramfs como a solução moderna para o early userspace.
Uma curiosidade que revela o cuidado técnico: várias variáveis globais foram renomeadas para desambiguar o que é “embutido” no kernel e o que é “externo” (passado pelo bootloader). Por exemplo, __initramfs_start/__initramfs_size viram __builtin_initramfs_start/__builtin_initramfs_size; e initrd_start/initrd_end tornam-se virt_external_initramfs_start/virt_external_initramfs_end. Parece detalhe — e é —, mas são esses detalhes que evitam bugs sutis e tornam o código mais legível para a próxima geração de mantenedores.
Por que isso é uma ótima notícia para quem mantém e usa Linux
Se você compila kernels, mantém defconfigs ou apenas gosta de saber como as coisas funcionam por baixo do capô, a resposta cabe numa palavra: simplificação. Menos caminhos de inicialização significam menos testes combinatoriais, menos suposições históricas e menos código que só existe para não quebrar o passado. Isso reduz o custo cognitivo de quem mantém o kernel e, a longo prazo, impacta positivamente a estabilidade.
Para distribuições e integradores, o recado é similar: ao abandonar a herança initrd, o ecossistema converge totalmente no initramfs, o que facilita documentação, tooling e debug. Scripts de inicialização, hooks e dracut/mkinitcpio da vida já orbitam esse modelo há muito tempo; a diferença agora é que o próprio kernel fecha a porta para a rota antiga.
E se alguém ainda dependia de um comportamento bem específico do initrd clássico? A recomendação é migrar — e já era, de fato, desde 2020. O initramfs oferece tudo que o early userspace precisa e continua sendo a solução moderna e totalmente suportada. O próprio tópico na LKML indica testes extensivos (com cross toolchains e QEMU) e dá caminhos para quem mantém arquiteturas menos comuns. Para quem quer conferir os detalhes operacionais citados pelo autor, ele referencia ferramentas como o [mkroot do Toybox] e os toolchains publicados por Rob Landley, além de apontar discussões anteriores sobre o acesso ao blob inicial via /sys/firmware/initrd (para cenários muito específicos), tudo documentado na mesma thread.
O pano de fundo histórico e o timing
Tecnicamente, o Linux initrd foi crucial num passado em que embutir drivers e stacks inteiras no kernel era a forma mais segura de garantir um boot controlado. O initramfs surgiu como evolução natural quando o kernel ganhou mecanismos melhores de descompressão e tmpfs/ramfs ofereceram um “chão” simples dentro da memória. De lá para cá, userspace inicial ficou mais poderoso, ferramentas de geração amadureceram e o early boot passou a acumular menos fricção.
A depreciação de 2020 foi o primeiro “tchau”. A série de 62 patches de setembro de 2025 é o “adeus” definitivo — com direito a faxina na casa inteira: remoção de arquivos específicos do initrd, poda de referências nos headers, ajustes em dezenas de defconfigs de arquiteturas e uma boa arrumação nos nomes de símbolos. É um marco histórico daqueles que não aparecem na splash screen, mas que você sente no dia a dia: documentações mais consistentes, parâmetros de boot que fazem sentido e um kernel com menos carga do passado.
Em resumo: o Linux está fazendo aquilo que o torna duradouro — remover o que não faz mais sentido, alinhar o que ficou torto com o tempo e deixar o caminho livre para o que realmente importa no boot de hoje.
