Como o linux sabe onde está o rootfs?

Em primeiro lugar, não se assuste com as referências a "2.6" nos documentos do kernel. Os kernels atuais ainda são membros da linha "2.6", mas passaram por duas rodadas de renumeração apenas para "fins de marketing" (então 2.6.40 se tornou 3.0 e 3.20 se tornou 4.0). Seu kernel 4.19 normalmente seria rotulado como 2.6.79.

Parece que há alguma confusão acontecendo aqui sobre o significado de "rootfs". O "rootfs" é um sistema de arquivos especial baseado em RAM usado internamente pelo kernel. É exatamente o mesmo que os sistemas de arquivos "tmpfs" que são comumente montados em locais como /run, /dev/shm, ou às vezes /tmp. (Bem, a menos que o recurso "tmpfs" não seja compilado no kernel, caso em que um "tmpfs" simplificado chamado "ramfs" é usado.) Esses sistemas de arquivos apenas vivem no pagecache, não há nenhum dispositivo de apoio para ramfs, enquanto o tmpfs é suportado por swap, se disponível.

O kernel, portanto, não precisa se preocupar em "encontrar" o "rootfs", mas precisa preenchê-lo de alguma forma, porque todo o cache de página está vazio na inicialização. É aí que o "arquivo initramfs" entra em ação. cpioIsso é apenas um arquivo (compactado) (não tarpelas razões mencionadas nos documentos) que é descompactado pelo kernel no "rootfs" vazio. Este arquivo pode ser incorporado diretamente na imagem do kernel, definindo CONFIG_INITRAMFS_SOURCEdurante a compilação, ou fornecido pelo bootloader (é isso que a initrdopção no GRUB faz). Esse arquivo geralmente é criado usando ferramentas de espaço do usuário como dracutou (confusamente) mkinitrd.

Se a imagem cpio não estiver disponível ou não contiver um executável /init, o kernel volta para um método diferente onde ele examina o root=argumento da linha de comando, interpreta-o como a localização de um sistema de arquivos raiz real, monta-o /e executa initdiretamente. No entanto, isso raramente é usado hoje em dia, pois requer todos os drivers de armazenamento e sistema de arquivos necessários compilados diretamente no kernel. Na maioria dos sistemas, o root=argumento não é usado pelo kernel, mas processado pelo /initinitramfs. Isso /init(que geralmente é um systemdou um script de shell) cuida de carregar os módulos necessários, montar o sistema de arquivos raiz real e alternar para ele.

Há muito tempo, um mecanismo diferente chamado "initrd" foi usado em vez do moderno "initramfs". O "initrd" ("init ramdisk") era um dispositivo de bloco baseado em RAM que foi inicializado com um sistema de arquivos real (como ext2), cuja imagem foi fornecida exatamente como o cpioarquivo moderno. É por isso que muitos lugares ainda usam o nome "initrd" para se referir a essas coisas de inicialização antecipada.

Portanto, se eu quiser que meus rootfs estejam na RAM, preciso definir CONFIG_INITRAMFS_SOURCE para apontar para meus rootfs (presumivelmente no formato cpio).

Essa é uma maneira de fazer isso, sim, mas não é a única maneira.

Se você tem um bootloader que pode ser configurado para carregar o kernel e o initramfs como arquivos separados, você não precisa usá-lo CONFIG_INITRAMFS_SOURCEdurante a construção do kernel. É suficiente ter CONFIG_BLK_DEV_INITRDdefinido na configuração do kernel. (Antes do initramfs havia uma versão mais antiga da técnica chamada initrd, e o nome antigo ainda aparece em alguns lugares.) O carregador de inicialização carregará o arquivo initramfs e, em seguida, preencherá algumas informações sobre sua localização e tamanho de memória em uma estrutura de dados em um local específico da imagem do kernel já carregada. O kernel possui rotinas internas que usarão essas informações para localizar o initramfs na RAM do sistema e descompactá-lo.

Ter o initramfs como um arquivo separado permitirá que você modifique o arquivo initramfs mais facilmente, e se o seu carregador de inicialização puder aceitar a entrada do usuário, talvez especifique outro arquivo initramfs a ser carregado em vez do arquivo normal no momento da inicialização. (Isso é muito útil se você tentar criar um initramfs personalizado e errar algumas coisas. Estive lá, fiz isso.)

Para um sistema x86 tradicional baseado em BIOS, você encontrará informações sobre esses detalhes em (fonte do kernel)/Documentation/x86/boot.txt . Os sistemas baseados em UEFI fazem isso de maneira um pouco diferente (também descrito no mesmo arquivo), e outras arquiteturas como ARM têm seus próprios conjuntos de detalhes sobre como passar informações do carregador de inicialização para o kernel.

Além disso, e se eu quiser que meus rootfs estejam no armazenamento físico (como eMMC, pen drive, etc.) e não na RAM?

Em sistemas não embarcados regulares, o initramfs normalmente conterá apenas a funcionalidade suficiente para ativar os subsistemas essenciais. Em um PC comum, esses geralmente seriam os drivers para o teclado, a tela e o driver do controlador de armazenamento para o sistema de arquivos raiz, além de quaisquer módulos e ferramentas do kernel necessários para ativar subsistemas como LVM, criptografia de disco e/ou RAID de software, se você usar esses recursos.

Assim que os subsistemas essenciais estiverem ativos e o sistema de arquivos raiz estiver acessível, o initramfs normalmente fará uma pivot_root(8)operação para alternar do initramfs para o sistema de arquivos raiz real. Mas um sistema embarcado, ou um utilitário especializado como o DBAN , pode empacotar tudo o que precisa no initramfs e nunca fazer a pivot_rootoperação.

Normalmente, os scripts e/ou ferramentas dentro do initramfs obterão as informações necessárias para localizar o sistema de arquivos raiz real a partir das opções na linha de comando do kernel. Mas você não precisa fazer isso: com um initramfs personalizado, você pode fazer algo como alternar para um sistema de arquivos raiz diferente se uma tecla ou botão do mouse específico for pressionado em um momento específico na sequência de inicialização.

Com uma configuração de armazenamento complexa (por exemplo, LVM criptografado em cima de um RAID de software, em um sistema que usa armazenamento SAN redundante de vários caminhos), todas as informações necessárias para ativar o sistema de arquivos raiz podem não caber na linha de comando do kernel, então você pode incluir o pedaços maiores em initramfs.

As distribuições modernas geralmente usam um gerador initramfs para construir um initramfs adaptado para cada kernel instalado. Diferentes distribuições costumavam ter seus próprios geradores initramfs: RedHat usado mkinitrdenquanto Debian tinha update-initramfs. Mas após a introdução systemddele parece que muitas distribuições estão padronizando dracutcomo um gerador initramfs.

Um arquivo initramfs moderno pode ser uma concatenação de vários .cpioarquivos e cada parte pode ou não ser compactada. Um arquivo initramfs típico em um sistema x86_64 moderno pode ter um arquivo de "atualização antecipada de microcódigo" como primeiro componente (geralmente apenas um único arquivo em um arquivo cpio descompactado, pois o arquivo de microcódigo é normalmente criptografado e, portanto, não é muito compactável. o conteúdo regular do initramfs, como um .cpioarquivo compactado.

Para obter uma compreensão mais profunda do seu sistema, recomendo que você extraia um arquivo initramfs para um diretório temporário e examine seu conteúdo. No Debian, existe uma unmkinitramfs(8)ferramenta que pode ser usada para extrair um arquivo initramfs de maneira direta. No RedHat 7, você pode precisar usar /usr/lib/dracut/skipcpio <initramfs file>para pular o arquivo de atualização de microcódigo e, em seguida, canalizar a saída resultante gzcatpara cpio -i -dextrair o conteúdo do initramfs para o diretório de trabalho atual. O Ubuntu pode usar lzcatno lugar do gzcat.