Como o Linux lida com uma partição / boot separada?

Question

Estou interessado em aprender sobre como o Linux lida com partições de inicialização separadas. Estou não interessado em realmente fazer isso, mas eu gostaria de saber como isso funciona sob o capô.

Considere um disco rígido sda , que tem duas partições sda1 e sda2 . Digamos que sda2 seja a root partition / que contém o sistema operacional Linux.

Meu entendimento é que o carregador de inicialização GRUB2 está montado em /boot . Entretanto, quando o diretório /boot estiver em uma partição separada sda2 , como isso pode acontecer antes que / seja realmente montado?

Como a interação entre o BIOS, o registro mestre de inicialização e o GRUB (ou os arquivos /boot ) ocorre com sucesso neste caso? Será que os dados em /boot não estão realmente montados no sistema de arquivos / neste estágio inicial?

Nota: esta questão trata da montagem a partição raiz, mas não discute uma partição de inicialização separada.

    

Answer 1

Aqui está o problema no seu entendimento:

My understanding is that the bootloader GRUB2, is mounted to /boot.

O GRUB não é "montado" na inicialização. O GRUB está instalado em /boot e é carregado no código do Registro mestre de inicialização. Aqui está uma visão geral simplificada do moderno processo de inicialização, assumindo uma distribuição GNU / Linux com um MBR / BIOS (não GPT / UEFI):

1. O BIOS é carregado.
2. O BIOS carrega a pequena parte do código que está no registro mestre de inicialização.
3. O GRUB não cabe em 440 bytes, o tamanho do registro mestre de inicialização. Portanto, o código que é carregado, na verdade, apenas analisa a tabela de partição, localiza a partição /boot (que, acredito, é determinada quando você instala o GRUB no Registro mestre de inicialização) e analisa as informações do sistema de arquivos. Em seguida, ele carrega o estágio 2 GRUB. (É aí que entra a simplificação.)
4. Estágio 2 O GRUB carrega tudo de que precisa, incluindo a configuração do GRUB, e apresenta um menu (ou não, dependendo da configuração do usuário).
5. Uma sequência de inicialização é escolhida. Isso pode ocorrer por um tempo limite, pelo usuário selecionando uma entrada de menu ou iniciando uma lista de comandos.
6. A sequência de inicialização começa a ser executada. Isso pode fazer várias coisas - por exemplo, carregar um kernel, carregamento em cadeia para outro gerenciador de inicialização - mas vamos supor que a seqüência de inicialização seja GNU / Linux padrão.
7. O GRUB carrega o kernel do Linux.
8. O GRUB carrega o ramdisk inicial .
9. O disco ram inicial monta / em /new_root (possivelmente criptograficamente desbloqueando-o), inicia o udev, inicia o reinício da troca, etc.
10. O disco RAM inicial usa o utilitário pivot_root para definir /new_root como% real/.
11. init é iniciado. As partições são montadas, os daemons são iniciados e o sistema inicializa.

Observe como o kernel é carregado apenas na etapa 7. Por causa disso, não há conceito de montagem até a etapa 7 . É por isso que /boot precisa ser montado novamente na etapa 9, embora o GRUB já o tenha usado.

Também pode ser útil examinar a seção GRUB 2 da página da Wikipédia no GRUB.

    

Answer 2

Question #1

My understanding is that the bootloader GRUB2, is mounted to /boot. When the directory /boot is on separate partition sda2, however, how is it that this can happen before / is actually mounted?

Eu não acho que você esteja entendendo bem aqui. Na página da Wikipedia do GNU GRUB :

trecho

When a computer is turned on, the computer's BIOS finds the configured primary bootable device (usually the computer's hard disk) and loads and executes the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk, and has the number 0 (sectors counting starts at 0). For a long time, the size of a sector has been 512 bytes, but since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks. As of October 2013, such hard disks are still accessed in 512-byte sectors, by utilizing the 512e emulation.

Em GRUB versão 2 , acontece o seguinte:

trecho

Booting the Computer

When power is turned on, the following happens:

• The hardware initializes, sets the CPU to real mode (no virtual memory) and jumps to fixed location 0xFFFF0 (hardwired in the CPU circuits)
• BIOS code stored in a ROM or flash-memory mapped to that location is therefore executed.
• The BIOS code looks at the BIOS config data to see which is the boot device. This BIOS config data can usually be edited by pressing some special key-sequence just after turning the power on, causing the BIOS configuration program to run. Among other things, the boot device can usually be selected here.
• The BIOS code loads the MBR of the boot device into RAM. Remember that an MBR is just 512 bytes! The loaded data is of course the program & data that grub-install dynamically created and wrote there when the grub-install program was executed.
• The BIOS code jumps to the start address of the loaded MBR (ie Grub code executes for the first time since power-on).
• Grub’s MBR code loads a single sector whose address is hard-wired into the MBR block. It then loops over the (address,len) pairs in that sector loading all that data from the disk into memory (ie loads the contents of file /boot/grub/core.img, or its “embedded” copy). The MBR code then jumps to the loaded code, ie “executes” the program in core.img.
• As described in the “Installing Grub” section, this trick of embedding the raw disk block addresses makes it possible to store core.img in space that is not in a partition, and that has never been formatted as a filesystem at all (“embedding”). And in this case, if core.img is modified, as long as the new version is “embedded” at the same location, the MBR code does not need to be updated.
• Alternatively, it is possible for the core.img to be inside a real filesystem, and for Grub to read the core.img file contents without having a driver for that filesystem. However in this case, if core.img is modified then the first block of the file may well be given a new address on disk; if this happens then the MBR must be updated to point to this new location. Nevertheless, as core.img is usually updated by running grub-install, this is not usually a problem.
• Note that theoretically, if core.img is on a different device than the MBR, and new hardware is added then the Grub-generated MBR record might not be able to correctly load the core.img file; the device-id on which the first sector of core.img is to be found is hard-wired into the MBR, not searched for. However there is no solution for this; there is no way to embed the equivalent of the Grub “search” command into the 512-byte MBR. This problem is not likely though; normally the core.img is embedded on the same device as the MBR. And once core.img has been loaded it can use search.mod to find all further /boot/grub files, and is therefore immune to hardware rearrangements.
• The executed core.img code now initializes all the modules that are built into it (linked into core.img); one of these modules will be a filesystem driver capable of reading the filesystem on which directory /boot/grub lives.
• It also registers a set of built-in commands: set, unset, ls, insmod.
• If a “config file” has been linked into core.img, this is then passed to a very simple build-in script parser for processing. Scripting commands in the config file can only invoke built-in or linked-in commands. Simple scenarios (eg booting a typical desktop computer from a local drive) need no config file; this facility is used for things like booting via pxe, remote nfs or when /boot/grub is on an LVM device.
• Core.img now loads file “/boot/grub/normal.mod” dynamically from disk, and jumps to its entry function. Note that this step requires the appropriate filesystem driver to be set up (ie built-in).

OBSERVAÇÃO:QuandovocêvêomenutípicodoGRUB2,ondevocêselecionaoOS/Kernelaserinicializado,vocêestáfazendoreferênciaaodiretório/boot/grubdosistemanesteponto.

Referências

• Inicializando o Linux no x86 usando o Grub2
• GNU GRUB - Wikipedia
• 6 estágios do processo de inicialização do Linux (seqüência de inicialização)
• Dentro do processo de inicialização do Linux
• Processo de inicialização do Linux
• Bootloader do GRUB 2 - Tutorial completo - Dedoimedo

Answer 3

O Linux (o kernel) não se importa com quantas partições de inicialização você possui. Carregar o kernel do disco é o trabalho do carregador de inicialização (por exemplo, grub , grub2 , lilo ) e essas ferramentas também não se importam com o número de locais em que um kernel pode estar localizado. Eles só se importam com a localização específica.

Como exemplo, minha partição de inicialização é /dev/md1 , que é um espelho RAID mdadm respaldado pelas partições físicas /dev/sde1 e /dev/sdf1 . Eu posso montá-los individualmente se eu quiser e, como tal, isso tecnicamente conta como tendo duas partições de inicialização, embora elas devam conter os mesmos dados.

Ter duas partições para / boot para mim é um problema de disponibilidade, mas elas podem ser igualmente diferentes / partições de inicialização. O próximo passo é como o bootloader sabe? Aqui está como:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

Este é um trecho de uma configuração de grub2 e você notará que as únicas diferenças são root=hd0,1 e root=hd1,1 que estabelecem qual partição de inicialização essa entrada faz referência.

Agora, dê uma olhada em uma bota para que você possa entender o que está acontecendo aqui.

• O BIOS lê o MBR do volume de inicialização e vai para o gerenciador de inicialização
• O bootloader (por exemplo, grub2 ) é configurado para saber qual dispositivo e partição contém seu kernel. O Grub2 acessa essa partição diretamente e carrega seu kernel na memória.
• O seu bootloader então entra no kernel e o kernel inicializa sua máquina.

O gerenciador de inicialização não se importa com quantas partições de inicialização você possui, ele apenas se importa onde elas estão e você deve informar essas informações.

O kernel não se importa com quantas partições de inicialização você tem, porque ele nunca precisa vê-las (você só precisa tê-las disponíveis para adicionar novos kernels, por exemplo).