Como os sistemas de arquivos suportam a inicialização de estilo “legado”?

1

Eu estou no processo de escrever um gerenciador de inicialização simples do sistema operacional (primeiro inicializando no modo herdado). Depois de entender o processo de inicialização ( MBR carregando o VBR , etc) Comecei a investigar as especificações de diferentes sistemas de arquivos para entender como eles lidavam com esse antigo estilo de inicialização.

Isso é necessário porque o Volume Boot Record (VBR) é, por design, localizado no disco no primeiro setor da partição "ativa". Em outras palavras, o valor de bytes do primeiro setor (normalmente 512 bytes) não é, na verdade, estruturas de dados do sistema de arquivos, mas o código de inicialização do sistema operacional.

Primeiro, olhei para o FAT por sua simplicidade. Para minha surpresa, encontrei referências ao " Setor de inicialização " incorporado à especificação. Especificamente, quando você formata um disco com o sistema de arquivos FAT, é possível "reservar" alguns setores no início para blocos especiais de código, como o VBR. Nesse caso, todas as estruturas de dados do sistema de arquivos são deslocadas por esse número de blocos reservados. Ótimo! Isso é exatamente o que eu estava procurando.

No entanto, não consegui encontrar algo semelhante em outros sistemas de arquivos (especificamente ext). Esses outros sistemas de arquivos devem suportar o estilo "legado" de inicialização (por exemplo, espaço para o VBR inicializar o SO) porque estavam disponíveis bem antes da especificação de inicialização do UEFI.

    
por sherrellbc 24.02.2018 / 19:35

1 resposta

2

These other filesystems must support the "legacy" style of booting (e.g. space for the VBR to bootstrap the OS) because they were available well before the UEFI boot specification.

Não, eles não precisam. Veja Manual GNU GRUB 2.02 :

The partition table format traditionally used on PC BIOS platforms is called the Master Boot Record (MBR) format; this is the format that allows up to four primary partitions and additional logical partitions. With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition.

Each of these has different problems. There is no way to reserve space in the embedding area with complete safety, and some proprietary software is known to use it to make it difficult for users to work around licensing restrictions; and systems are sometimes partitioned without leaving enough space before the first partition. On the other hand, installing to a filesystem means that GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the /boot filesystem is on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers.

The GRUB development team generally recommends embedding GRUB before the first partition, unless you have special requirements. You must ensure that the first partition starts at least 31 KiB (63 sectors) from the start of the disk; on modern disks, it is often a performance advantage to align partitions on larger boundaries anyway, so the first partition might start 1 MiB from the start of the disk.

Isso significa que um gerenciador de inicialização pode residir antes do primeiro VBR ou até mesmo dentro de um sistema de arquivos em si.

    
por 24.02.2018 / 19:59