Por que precisamos de um gerenciador de boot?

Por que precisamos de um gerenciador de boot?

Após a inicialização do BIOS, ou algo semelhante que sirva de firmware, o controle é passado para o bootloader, até onde eu sei.

Por que o BIOS não consegue carregar o kernel do sistema operacional diretamente?

Além disso, o manual do GRUB diz:resumidamente, um gerenciador de inicialização é o primeiro programa de software executado quando um computador é inicializado. O BIOS não é o primeiro programa a ser executado?

Responder1

Um BIOS precisaria saber como carregar um kernel, e isso tornaria o BIOS excessivamente complicado: imagine um BIOS que precise saber como carregar os diversos sistemas operacionais disponíveis, como passar parâmetros do kernel para eles, etc.

Assim, ele apenas inicializa o hardware e salta para um local conhecido onde o bootloader está armazenado; então, o controle é passado para ele.

DeO COMO FAZER Fundamentos do Unix e da Internet:

Você pode estar se perguntando por que o BIOS não carrega o kernel diretamente – por que o processo de duas etapas com o gerenciador de boot? Bem, o BIOS não é muito inteligente. Na verdade, é muito estúpido e o Linux não o utiliza após a inicialização. Ele foi originalmente escrito para PCs primitivos de 8 bits com discos minúsculos e literalmente não consegue acessar disco suficiente para carregar o kernel diretamente. A etapa do carregador de boot também permite iniciar um dos vários sistemas operacionais em diferentes locais do disco, no caso improvável de o Unix não ser bom o suficiente para você.

Quanto ao BIOS ser o primeiro programa a ser executado: (deWikipédia)

O software BIOS está integrado no PC e é o primeiro código executado por um PC quando ligado ('firmware de inicialização').

Mas um firmwareéProgramas. Então, eu diria que o manual do GRUB é pelo menos confuso nessa parte; o bootloader pode ser visto como o primeirousuário definidosoftware que roda no computador.

Responder2

O motivo é a flexibilidade. Você pode ter vários sistemas operacionais diferentes em um disco rígido (Windows, Linux, etc.) ou pode ter várias versões diferentes do mesmo sistema operacional. Portanto, é melhor ter um código independente do SO que saiba onde reside cada SO instalado no disco rígido, como carregar cada um deles, qual carregar, se deve apresentar um menu ou não, etc. um gerenciador de inicialização.

O BIOS carrega e executa código localizado em um local predefinido no disco rígido (primeiro setor). Chamamos esse código de bootloader, mas tecnicamente se você instalou o Windows em um disco rígido vazio, esse código também é instalado pelo Windows, então você pode chamá-lo de parte do Windows, especialmente porque o bootloader do Windows não pode carregar nenhum outro sistema operacional além do Windows.

Em relação ao primeiro programa de software executado quando um computador é inicializado: a distinção firmware/software é muito tênue e o processo de inicialização do computador moderno é muito complicado. O BIOS em si também não é um programa monolítico, mas vários estágios distintos encadeados. No entanto, o bootloader é o primeiroalterável pelo usuáriocódigo que é executado. Este é o primeiro trecho de código que o usuário pode danificar, apagar, infectar com um vírus, etc. Então, suponho que, embora tecnicamente o BIOS seja o primeiro software a ser executado, o bootloader é o primeiro no sentido de que, se o computador não inicializar, o usuário precisa para verificar se está tudo bem.

Responder3

Por que o BIOS não consegue carregar o kernel do sistema operacional diretamente?

Três razões:

  • O BIOS na plataforma original do PC, quando foi introduzido em 1981, deveria funcionar na mesma função do sistema operacional CP/M - ou seja, uma fina camada de abstração para alguns dispositivos e um carregador de inicialização de disco simples. O CP/M tinha outra camada chamada "BDOS" que cuidava do sistema de arquivos. O DOS era semelhante ao CP/M em muitos aspectos, pois era o sistema operacional em voga na época e era estruturado de forma semelhante. O BIOS foi projetado para lidar com aspectos específicos de hardware da plataforma, uma função que os drivers nos sistemas operacionais desempenham agora.

  • A noção de um sistema de arquivos separado do sistema operacional ainda não se consolidou.

  • Naquela época, RAM e ROM eram recursos caros e escassos. O PC IBM 5150 original poderia ser obtido com apenas 16K de RAM (referência). O tamanho da ROM deste sistema era de 48K e incluía um interpretador BASIC. Também não existia um sistema de arquivos padrão naquela época.

Como o DOS cresceu e se tornou o sistema operacional mais popular para esta plataforma, e depois o Windows, que funcionou com essa configuração, ninguém pensou em estender o BIOS dessa maneira para incluir capacidade real de bootloading.

Não tenho certeza dos recursos do UEFI - ele pode ter capacidade real de bootloading que não é usado pelo Windows por um motivo ou outro (o Windows insiste em usar seu próprio gerenciador de inicialização quando você o instala). Outros firmwares não BIOS, como o U-Boot e aqueles em muitos telefones e roteadores, carregam e executam kernels diretamente. Não houve uma razão técnica para isso desde quando os BIOS começaram a ter espaço na ROM para fazer mais coisas.

informação relacionada