O ramdisk inicial (initrd) é tipicamente uma versão simplificada do sistema de arquivos raiz contendo apenas o que é necessário para montar o sistema de arquivos raiz real e entregar a inicialização para ele.
O initrd existe porque nos sistemas modernos, o gerenciador de inicialização não pode ser inteligente o suficiente para encontrar o sistema de arquivos raiz de forma confiável. Existem muitas possibilidades para um programa tão pequeno como o carregador de boot. Considere o NFS root, placas RAID não padronizadas, etc. O gerenciador de partida tem que fazer seu trabalho usando apenas o BIOS mais qualquer código que possa ser abarrotado no setor de inicialização.
O initrd é armazenado em algum lugar onde o carregador de inicialização pode encontrar, e é pequeno o suficiente para que o espaço extra que ele ocupa normalmente não incomode ninguém. (Em pequenos sistemas embarcados, geralmente não há raiz "real", apenas o initrd.)
O initrd é precioso: seu conteúdo tem que ser preservado sob todas as condições, porque se o initrd quebrar, o sistema não pode inicializar. Uma escolha de design feita por seus projetistas para garantir isso é fazer com que o carregador de boot carregue o initrd somente leitura. Existem outros princípios que também contribuem para isso, como no caso de sistemas pequenos em que não há raiz "real", você ainda monta /tmp , /var/cache e outros para armazenar as coisas separadamente. Mudar o initrd é feito raramente, e depois deve ser feito com muito cuidado.
Voltando ao caso normal em que é um sistema de arquivos raiz real, ele é inicialmente montado somente para leitura porque o initrd era. Em seguida, ele é mantido como somente leitura pelo maior tempo possível pelas mesmas razões. Qualquer gravação na raiz real que precisa ser feita é adiada até que o sistema seja inicializado, de preferência, ou pelo menos até o final do processo de inicialização, quando essa preferência não puder ser satisfeita.
A coisa mais importante que acontece durante esta fase de somente leitura é que o sistema de arquivos raiz é verificado para ver se foi desmontado de forma limpa. Isso é algo que o gerenciador de partida poderia fazer em vez de deixá-lo para o initrd, mas o que aconteceria se o sistema de arquivos raiz não fosse desmontado corretamente? Em seguida, ele deve chamar fsck para verificar e, possivelmente, consertá-lo. Então, onde initrd get fsck , se era responsável por este passo, em vez de esperar até o handoff para a raiz "real"? Você poderia dizer que precisa copiar fsck no initrd ao criá-lo, mas agora ele é maior. E além disso, qual fsck você copiará? Os sistemas Linux usam regularmente uma dúzia de sistemas de arquivos diferentes. Você copia apenas o necessário para a raiz real no momento em que o initrd é criado? Você aumenta o tamanho de initrd copiando todos os programas fsck.foo disponíveis para ele, no caso de o sistema de arquivos raiz ser posteriormente migrado para algum outro tipo de sistema de arquivos, e alguém esquecer de reconstruir o initrd?
Os arquitetos do sistema de inicialização do Linux escolheram sabiamente não sobrecarregar o initrd com esses problemas. Eles delegaram a verificação do sistema de arquivos raiz real para o sistema de arquivos raiz real, já que ele está em melhor posição para fazer isso do que o initrd.
Uma vez que o processo de inicialização tenha prosseguido o suficiente para que seja seguro fazê-lo, o initrd será trocado de debaixo da raiz real com pivot_root(8) , e o sistema de arquivos é remontado no modo de leitura / gravação.