Próximo, tentarei responder à sua pergunta, mas para uma descrição mais abrangente do processo de inicialização, tente o artigo da IBM .
Ok, suponho que você esteja usando o GRUB ou GRUB2 como seu carregador de inicialização para obter explicações. Primeiro, quando o BIOS acessa seu disco para carregar o carregador de inicialização, ele usa suas rotinas internas para acesso ao disco, que são armazenadas na famosa interrupção de 13h. O gerenciador de inicialização (e o kernel na fase de configuração) fazem uso dessas rotinas quando acessam o disco. Observe que o BIOS é executado no modo real (16 bits) do processador, portanto, não pode endereçar mais de 2 ^ 20 bytes de RAM (2 ^ 20 e não 2 ^ 16 porque cada endereço no modo real é composto por segmento_address * 16 + deslocamento , onde o endereço do segmento e o deslocamento são de 16 bits, consulte http://en.wikipedia.org/wiki/X86_memory_segmentation ). Portanto, essas rotinas não podem acessar mais de 1 MiB de RAM, o que é uma limitação estrita e um grande inconveniente.
O BIOS carrega o código do carregador de inicialização diretamente do MBR - os primeiros 512 bytes do seu disco e o executa. Se você estiver usando o GRUB, esse código será o estágio 1. do GRUB. Esse código carregará o estágio 1.5 do GRUB, localizado nos primeiros 32 KiB de espaço em disco, chamado região de compatibilidade do DOS ou em um endereço fixo do sistema de arquivos. Ele não precisa entender o sistema de arquivos para fazer isso, porque o estágio 1.5 está no sistema de arquivos, é um código "bruto" e pode ser carregado diretamente na RAM e executado: http://www.pixelbeat.org/ docs / disk / . A carga do stage1.5 do disco para a RAM faz uso das rotinas de acesso ao disco do BIOS.
O Stage1.5 contém os utilitários do sistema de arquivos, para que ele possa ler o stage2 do sistema de arquivos (bem, ele ainda usa o BIOS 13h para ler do disco para a RAM, mas agora pode decifrar as informações do sistema de arquivos sobre inodes etc. e obter o código bruto do disco). Os BIOS mais antigos podem não conseguir acessar todo o HD devido a limitações no modo de endereçamento de disco - eles podem usar o sistema Cylinder-Head-Sector, incapaz de endereçar mais de 8 GiB de espaço em disco: http: //en.wikipedia. org / wiki / Setor de cabeçotes .
O Stage2 carrega o kernel na RAM (novamente, usando os utilitários de disco do BIOS). Se for 2.6+ ou mais, ele também possui o initramfs compilado, portanto, não é necessário carregá-lo. Se for um kernel mais antigo, o carregador de inicialização também carrega imagem initrd independente na memória, para que o kernel possa montá-lo e obter drivers para montar o sistema de arquivos real a partir do disco.
O problema é que o kernel (e ramdisk) pesa mais de 1 MiB; portanto, para carregá-los na RAM, você precisa carregar o kernel no primeiro 1 MiB, depois pular para o modo protegido (32 bits) e mover o kernel carregado para a memória alta (livre o primeiro 1 MiB para o modo real), depois retorne ao modo real (16 bits) novamente, instale o ramdisk do disco para o primeiro 1 MiB (se for um initrd separado e um kernel mais antigo), possivelmente mude para o modo protegido (32 bits) novamente, coloque-o onde ele pertence, possivelmente volte ao modo real (ou não: /programming/4821911/does-grub-switch-to-protected-mode ) e execute o código do kernel. Aviso: não tenho certeza absoluta sobre o rigor e a precisão desta parte da descrição.
Agora, quando você finalmente executa o kernel, já o possui e o ramdisk foi carregado na RAM pelo gerenciador de inicialização , para que o kernel possa usar os utilitários de disco do ramdisk para montar seu sistema de arquivos raiz real e fazer a rotação do root. Os drivers ramfs estão presentes no kernel, para que ele possa entender o conteúdo do initramfs, é claro.
/bootpartição). O kernel não está carregado neste momento - é o stage1.5 do grub, que está acessando o stage2 no/bootsistema de arquivos (por exemplo, no/boot/grubarquivo) através de seus drivers minimalistas do sistema de arquivos. O kernel também poderá ler da/bootpartição, mas isso acontecerá mais tarde, após a execução do código grub2 e o carregamento do kernel, e depois que o kernel ler o initramfs. Você está falando doinit.shinitramfs? Ele reside na/bootpartição do seu disco rígido, então o stage2 do grub o coloca na RAM e o Kernel lê a partir da RAM.Eu acredito que tudo se resume ao que suporta determinados gerenciadores de inicialização. Por exemplo. ele não precisa conhecer o sistema de arquivos específico da sua partição combinada (inicialização + raiz). Nesse caso, você apenas cria uma partição de inicialização separada, na condição de que ela funcione com o seu carregador de inicialização, e qualquer outra complexidade de como montar sua partição raiz é deixada no kernel e na imagem initrd inicializada na partição de inicialização. O carregador de inicialização sabe como acessar os dispositivos SCSI (e outros dispositivos também, dependendo de qual carregador de inicialização é usado), usando seus próprios drivers ou utilizando as rotinas do BIOS. Além disso, ele sabe ler alguns sistemas de arquivos, etc.
Considere, por exemplo. A maneira UEFI de inicializar, onde o firmware UEFI já sabe como acessar a partição EFI, lê-la e carregar o kernel Linux a partir daí, sem a necessidade de um gerenciador de inicialização intermediário. Nesse caso, a imagem do linux vive separada da partição raiz e o firmware UEFI não precisa conhecer todos os sistemas de arquivos exóticos para acessá-la. Eu acredito que a separação das imagens "boot" da partição "root" faz muito sentido. Caso contrário, isso é necessário ao configurar a criptografia do sistema de arquivos raiz.
fonte
Apenas para constar, se um gerenciador de inicialização não carregar o initrd, vale a pena testar outro gerenciador de inicialização; Acabei de enfrentar uma situação como essa quando o LILO ignorou silenciosamente um initrd corretamente especificado de tamanho médio (<4Mb; rootfs ext4 únicos em um SSD SATA; GPT) e o GRUB 2.00 foi bem-sucedido.
O processo de inicialização terminou rapidamente com um típico
fonte