Does a boot loader unmount the ramdisk […] ?
Não.
Later, the kernel unmounts the ramdisk and mounts the root file system on the hard drive. And then, starts the initialization stage by executing the first process.
Isso está errado.
O initramfs contém um programa chamado /init . Este programa é executado e é o primeiro (usuário) processo enquanto o initramfs ainda está lá . De fato, é esse programa que dispara qualquer desmontagem que ocorre.
Este é o programa /init usado no Debian 9 Linux . O Fedora tem um sistema similar chamado Dracut . Como você pode ver, o script carrega módulos, executa ganchos, monta o sistema de arquivos raiz final e, finalmente, sobrepõe-se ao programa run-init , que pode ser encontrado no pacote klibc-utils. (Versões anteriores usavam run-init ou switch_root de acordo com o que estava disponível.) O Dracut ainda usa switch_root . Dracut neste ponto gerou um todo systemd-udevd subsystem que executou dispositivos autodetectados e executou os daemons e montou volumes a partir desses dispositivos. Os daemons gerados por systemd-udevd para os DASDs continuam sendo executados em paralelo com switch_root .
O programa run-init em por sua vez, exclui o conteúdo do initramfs, chroot s para o novo sistema de arquivos raiz, abre seu /dev/console e se sobrepõe a qualquer que seja o programa init nesse sistema de arquivos , que ele sabe de uma variável chamada init na linha de comando do kernel ou um padrão para essa variável assumida por o primeiro programa /init . switch_root faz o mesmo, embora com algumas pequenas diferenças. Dracut passa o nome do programa init que ele obteve da mesma forma da linha de comando do kernel .
Como você pode ver, nenhum o kernel nem um gerenciador de partida aciona nada disso. O carregador de boot está bem fora de cena quando o programa /init é iniciado como processo # 1, e o kernel simplesmente faz o programa /init , os programas nos ganchos que ele gera e os dois mais adiante. programas que ele se sobrepõe, diga.
E não, não há nenhum ponto neste processo, a partir do momento em que o processo # 1 é iniciado com o programa /init do initramfs em diante, onde é possível não ter nenhum sistema de arquivos montado . Há sempre pelo menos um processo em execução, e esse processo deve ter um diretório de trabalho, um diretório raiz e um arquivo de imagem de programa, os quais devem referenciar vnodes de um volume montado em algum lugar .
Você observará que o initramfs original só pode desaparecer quando o último ponto de montagem é movido e o último processo a ser usado, como o diretório atual por processo, o diretório raiz por processo ou o arquivo de imagem do programa. vai embora - ou, como run-init e switch_root do, alterna o diretório de trabalho eo diretório raiz para algum outro volume e se sobrepõe a uma imagem de programa de um arquivo de algum outro volume. Note que as pessoas do systemd acomodam a possibilidade de que o initramfs de fato não desapareça, porque há programas rodando a partir de imagens daquele volume, e permanece presente por toda a vida do sistema.
Então, o que realmente acontece é que tanto o initramfs original quanto o sistema de arquivos raiz final estão ambos presentes em um ponto do processo, e de fato possivelmente a partir de então. Longe de existir um ponto em que existem sistemas de arquivos raiz zero , há um ponto em que há múltiplos sistemas de arquivos raiz e então (conforme as referências ao initramfs desaparecem) cai de volta para um novamente. (Observe que os sistemas de arquivos para /proc , /sys , /dev , /run , /dev/shm e /dev/pts estão presentes no momento de run-init / switch_root em execução, então o total contagem de sistemas de arquivos montados, root e outros, permanece bem acima de dois ao longo do processo de bootstrap.)
Leitura adicional
- Harald Hoyer (2013-10). dracut . versão 3.0. kernel.org.
- Lennart Poettering e cols. (2013). systemd e Storage Daemons para o sistema de arquivos raiz . freedesktop.org.