Configurando o gerenciador de boot

AMD64 Manual
Installation
Sobre a instalação
Escolhendo a mídia
Configurando a rede
Preparando os discos
Instalando o stage3
Instalando o sistema base
Configurando o kernel
Configurando o sistema
Instalando as ferramentas
Configurando o gerenciador de boot
Finalizando
Trabalhando com o Gentoo
Introdução ao Portage
USE flags
Recursos do Portage
Sistema initscript
Variáveis de ambiente
Trabalhando com o portage
Arquivos e diretórios
Variáveis
Misturando ramos de software
Ferramentas adicionais
Árvore customizada do Portage
Recursos avançados
Configuração de rede
Iniciando
Configuração avançada
Uso de rede modular
Rede sem fio
Adicionando funcionalidade
Gerenciamento dinâmico

Selecionando um gerenciador de boot

Com o kernel do Linux configurado, as ferramentas do sistema instaladas e os arquivos de configuração editados, é hora de instalar a última parte importante de uma instalação Linux: o gerenciador de boot.

O gerenciador de boot é responsável por carregar o kernel do Linux no momento do boot - sem ele, o sistema não saberia como proceder quando fosse apertado o botão de ligar.

Para o amd64, documentamos como configurar o GRUB2 ou LILO para sistemas baseados em BIOS e o GRUB2 ou efibootmgr para sistemas UEFI.

Nesta seção do Manual foi feita uma separação entre "fazer o emerge" do pacote do carregador de boot e "instalar" um carregador de boot em um disco do sistema. Aqui o termo "emerge" será usado para solicitar ao Portage tornar o pacote de software disponível ao sistema. O termo "instalar" irá significar fazer a cópia dos arquivos do carregador de boot ou fisicamente modificar as seções apropriadas do drive de disco do sistema de maneira a tornar o carregador de boot "ativo e pronto para operação" no na próxima reinicialização.

Default: GRUB2

Por padrão, a maioria dos sistemas Gentoo agora tende a usar GRUB2 (encontrado no pacote sys-boot/grub), que é o sucessor direto do GRUB Legacy. Com nenhuma configuração adicional, o GRUB2 felizmente suporta sistemas mais antigos com BIOS ("pc"). Com um pouco de configuração, necessário antes da compilação, o GRUB2 pode suportar mais de meia dúzia de plataformas adicionais. Para mais informação, consulte a Seção de prerequisitos do artigo GRUB2.

Emerge

Quando usando um sistema de BIOS antiga que suporta apenas tabelas de partições MBR, nenhuma configuração adicional é necessária para emerge o GRUB:

root #emerge --ask --verbose sys-boot/grub:2

Uma nota para os usuários UEFI: executar o comando acima irá mostrar os valores GRUB_PLATFORMS habilitados antes de se fazer o emerge. Quando usarem sistemas UEFI, os usuários irão precisar ter certeza que GRUB_PLATFORMS="efi-64" está habilitado (como é o caso por padrão). Se isso não for necessário para a configuração, GRUB_PLATFORMS="efi-64" precisa ser adicionado ao arquivo /etc/portage/make.conf antes de fazer o emerge do GRUB2 para que este pacote seja compilado com a funcionalidade EFI:

root #echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf

root #emerge --ask sys-boot/grub:2

Se por alguma razão foi feito emerge do GRUB2 sem habilitar GRUB_PLATFORMS="efi-64", a linha (como mostrada acima) pode ser adicionada ao make.conf e então as dependências do conjunto de pacotes world recalculadas passando-se as opções --update --newuse ao emerge:

root #emerge --ask --update --newuse --verbose sys-boot/grub:2

O software GRUB2 está agora adicionado ao sistema, mas não está instalado ainda.

Instale

Em seguida, instale os arquivos do GRUB2 necessários no diretório /boot/grub/ com o comando grub-install. Assumindo que o primeiro disco (aquele do qual o sistema dá boot) é /dev/sda, um dos seguintes comandos fará isso:

• Se usar BIOS:

root #grub-install /dev/sda

For DOS/Legacy BIOS systems:

root #grub-install /dev/sda

• Se usar UEFI:

Importante
Certifique-se que a partição do sistema EFI tenha sido montada antes de rodar o grub-install. É possível que o grub-install instale o arquivo do GRUB EFI (grubx64.efi) no diretório errado sem prover nenhuma indicação de que o diretório errado foi usado.

For UEFI systems:

root #grub-install --target=x86_64-efi --efi-directory=/boot

Upon successful installation, the output should match the output of the previous command. If the output does not match exactly, then proceed to Debugging GRUB, otherwise jump to the Configure step.

Optional: Secure Boot

To successfully boot with secure boot enabled the signing certificate must either be accepted by the UEFI firmware, or shim must be used as a pre-loader. Shim is pre-signed with the third-party Microsoft Certificate, accepted by default by most UEFI motherboards.

How to configure the UEFI firmware to accept custom keys depends on the firmware vendor, which is beyond the scope of the handbook. Below is shown how to setup shim instead. Here it is assumed that the user has already followed the instructions in the previous sections to generate a signing key and to configure portage to use it. If this is not the case please return first to the Kernel installation section.

The package sys-boot/grub installs a prebuilt and signed stand-alone EFI executable if the secureboot USE flag is enabled. Install the required packages and copy the stand-alone grub, Shim, and the MokManager to the same directory on the EFI System Partition. For example:

root #emerge sys-boot/grub sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/Gentoo/shimx64.efi

root #cp /usr/share/shim/mmx64.efi /efi/EFI/Gentoo/mmx64.efi

root #cp /usr/lib/grub/grub-x86_64.efi.signed /efi/EFI/Gentoo/grubx64.efi

Next register the signing key in shims MOKlist, this requires keys in the DER format, whereas sbsign and the kernel build system expect keys in the PEM format. In the previous sections of the handbook an example was shown to generate such a signing PEM key, this key must now be converted to the DER format:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

Nota
The path used here must be the path to the pem file containing the certificate belonging to the generated key. In this example both key and certificate are in the same pem file.

Then the converted certificate can be imported into Shims MOKlist, this command will ask to set some password for the import request:

root #mokutil --import /path/to/kernel_key.der

Nota
When the currently booted kernel already trusts the certificate being imported, the message "Already in kernel trusted keyring." will be returned here. If this happens, re-run the above command with the argument --ignore-keyring added.

Next, register Shim with the UEFI firmware. In the following command, boot-disk and boot-partition-id must be replaced with the disk and partition identifier of the EFI system partition:

root #efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\Gentoo\shimx64.efi' --label 'GRUB via Shim' --unicode

Note that this prebuilt and signed stand-alone version of grub reads the grub.cfg from a different location then usual. Instead of the default /boot/grub/grub.cfg the config file should be in the same directory that the grub EFI executable is in, e.g. /efi/EFI/Gentoo/grub.cfg. When sys-kernel/installkernel is used to install the kernel and update the grub configuration then the GRUB_CFG environment variable may be used to override the usual location of the grub config file.

For example:

root #grub-mkconfig -o /efi/EFI/Gentoo/grub.cfg

Or, via installkernel:

FILE /etc/env.d/99grub

GRUB_CFG=/efi/EFI/Gentoo/grub.cfg

root #env-update

Nota
The import process will not be completed until the system is rebooted. After completing all steps in the handbook, restart the system and Shim will load, it will find the import request registered by mokutil. The MokManager application will start and ask for the password that was set when creating the import request. Follow the on-screen instructions to complete the import of the certificate, then reboot the system into the UEFI menu and enable the Secure Boot setting.

Debugging GRUB

When debugging GRUB, there are a couple of quick fixes that may result in a bootable installation without having to reboot to a new live image environment.

In the event that "EFI variables are not supported on this system" is displayed somewhere in the output, it is likely the live image was not booted in EFI mode and is presently in Legacy BIOS boot mode. The solution is to try the removable GRUB step mentioned below. This will overwrite the executable EFI file located at /EFI/BOOT/BOOTX64.EFI. Upon rebooting in EFI mode, the motherboard firmware may execute this default boot entry and execute GRUB.

Importante
Se o comando grub-install returnar erro como Could not prepare Boot variable: Read-only file system, pode ser necessário remontar o ponto de montagem especial efivars como de leitura e escrita de modo que o comando tenha sucesso:

root #mount -o remount,rw /sys/firmware/efi/efivars

root #mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivars

This is caused by certain non-official Gentoo environments not mounting the special EFI filesystem by default. If the previous command does not run, then reboot using an official Gentoo live image environment in EFI mode.

Alguns fabricantes de placas-mãe parecem suportar apenas o diretório /efi/boot/ como local para o arquivo .EFI na partição de Sistema EFI (ESP). O instalador do GRUB pode executar essa operação automaticamente através da opção --removable. Verifique se a partição ESP está montada antes de executar os comandos a seguir. Presumindo que a ESP está montada em /boot/efi (como sugerido anteriormente), execute:

root #grub-install --target=x86_64-efi --efi-directory=/boot --removable

Isso cria o diretório default definido pela especificação UEFI e então copia o arquivo grubx64.efi para a localização EFI 'default' definida por essa especificação.

Configure

Em seguida, gere a configuração do GRUB2 baseada na configuração do usuário especificada no arquivo /etc/default/grub e nos scripts /etc/grub.d. Na maioria dos casos, nenhuma configuração é necessária pois o GRUB2 irá detectar automaticamente qual kernel dar boot (o mais recente disponível em /boot/) e qual é o sistema de arquivos raiz. É possível também acrescentar parâmetros para o kernel em /etc/default/grub usando a variável GRUB_CMDLINE_LINUX.

Para gerar a configuração final do GRUB2, execute o comando grub-mkconfig:

root #grub-mkconfig -o /boot/grub/grub.cfg

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-6.6.21-gentoo
Found initrd image: /boot/initramfs-genkernel-amd64-6.6.21-gentoo
done

A saída do comando deve mostrar que pelo menos uma imagem do Linux foi encontrada, já que são necessárias para inicializar o sistema. Se foi criado um initramfs ou o genkernel foi usado para criar o kernel, a imagem correta do initrd deve ser detectada também. Se não for o caso, vá para o diretório /boot/ e cheque seu conteúdo usando ls. Se os arquivos estiverem realmente ausentes, retorne às instruções de configuração e instalação do kernel.

Dica
O utilitário os-prober pode ser usado em conjunto com o GRUB2 para detectar outros sistemas operacionais no drives conectados. Windows 7, 8.1, 10 e outras distribuições Linux são detectáveis. Quem desejar sistemas dual boot devem fazer emerge do pacote sys-boot/os-prober e então executar novamente o comando grub-mkconfig (como visto acima). Se problemas de detecção forem encontrados tenha certeza de ler o artigo GRUB2 inteiramente antes de procurar suporte da comunidade Gentoo.

Alternative 1: systemd-boot

Another option is systemd-boot, which works on both OpenRC and systemd machines. It is a thin chainloader and works well with secure boot.

Emerge

To install systemd-boot, enable the boot USE flag and re-install sys-apps/systemd (for systemd systems) or sys-apps/systemd-utils (for OpenRC systems):

FILE /etc/portage/package.use/systemd-boot

sys-apps/systemd boot
sys-apps/systemd-utils boot

root #emerge --ask sys-apps/systemd

Or

root #emerge --ask sys-apps/systemd-utils

Installation

Now, install the systemd-boot loader to the EFI System Partition:

root #bootctl install

Importante
Make sure the EFI system partition has been mounted before running bootctl install.

When using this bootloader, before rebooting, verify that a new bootable entry exists using:

root #bootctl list

Aviso
The kernel command line for new systemd-boot entries is read from /etc/kernel/cmdline or /usr/lib/kernel/cmdline. If neither file is present, then the kernel command line of the currently booted kernel is re-used (/proc/cmdline). On new installs it might therefore happen that the kernel command line of the live CD is accidentally used to boot the new kernel. The kernel command line for registered entries can be checked with:

root #bootctl list

If this does not show the desired kernel command line then create /etc/kernel/cmdline containing the correct kernel command line and re-install the kernel.

If no new entry exists, ensure the sys-kernel/installkernel package has been installed with the systemd and systemd-boot USE flags enabled, and re-run the kernel installation.

For the distribution kernels:

root #emerge --ask --config sys-kernel/gentoo-kernel

For a manually configured and compiled kernel:

root #make install

Importante
When installing kernels for systemd-boot, no root= kernel command line argument is added by default. On systemd systems that are using an initramfs users may rely instead on systemd-gpt-auto-generator to automatically find the root partition at boot. Otherwise users should manually specify the location of the root partition by setting root= in /etc/kernel/cmdline as well as any other kernel command line arguments that should be used. And then reinstalling the kernel as described above.

Optional: Secure Boot

When the secureboot USE flag is enabled, the systemd-boot EFI executable will be signed by portage automatically. Furthermore, bootctl install will automatically install the signed version.

To successfully boot with secure boot enabled the used certificate must either be accepted by the UEFI firmware, or shim must be used as a pre-loader. Shim is pre-signed with the third-party Microsoft Certificate, accepted by default by most UEFI motherboards.

How to configure the UEFI firmware to accept custom keys depends on the firmware vendor, which is beyond the scope of the handbook. Below is shown how to setup shim instead. Here it is assumed that the user has already followed the instructions in the previous sections to generate a signing key and to configure portage to use it. If this is not the case please return first to the Kernel installation section.

root #emerge --ask sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #bootctl install --no-variables

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/systemd/shimx64.efi

root #cp /usr/share/shim/mmx64.efi /efi/EFI/systemd/mmx64.efi

Shims MOKlist requires keys in the DER format, whereas sbsign and the kernel build system expect keys in the PEM format. In the previous sections of the handbook an example was shown to generate such a signing PEM key, this key must now be converted to the DER format:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

Nota
The path used here must be the path to the pem file containing the certificate belonging to the generated key. In this example both key and certificate are in the same pem file.

Then the converted certificate can be imported into Shims MOKlist:

root #mokutil --import /path/to/kernel_key.der

Nota
When the currently booted kernel already trusts the certificate being imported, the message "Already in kernel trusted keyring." will be returned here. If this happens, re-run the above command with the argument --ignore-keyring added.

And finally we register Shim with the UEFI firmware. In the following command, boot-disk and boot-partition-id must be replaced with the disk and partition identifier of the EFI system partition:

root #efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\systemd\shimx64.efi' --label 'Systemd-boot via Shim' --unicode '\EFI\systemd\systemd-bootx64.efi'

Nota
The import process will not be completed until the system is rebooted. After completing all steps in the handbook, restart the system and Shim will load, it will find the import request registered by mokutil. The MokManager application will start and ask for the password that was set when creating the import request. Follow the on-screen instructions to complete the import of the certificate, then reboot the system into the UEFI menu and enable the Secure Boot setting.

Alternativa 2: Usando o efibootmgr

Em sistemas baseados em UEFI, o firmware UEFI no sistema (ou seja, o gerenciador de boot primário) pode ser instruído diretamente para procurar entradas de boot UEFI. Tais sistemas não precisam de gerenciadores de boot adicionais (também conhecidos como secundários) tais como o GRUB2 para ajudar a inicializar o sistema. Dito isso, a razão para existirem gerenciadores de boot baseados em EFI tais como o GRUB2 é "estender" as funcionalidades dos sistemas UEFI durante o processo de boot. Usar o efibootmgr é na verdade para aqueles que desejam usar uma abordagem minimalista (e mais rígida) para dar boot no sistema; usar o GRUB2 (ver acima) é mais fácil para a maioria dos usuários porque oferece uma forma mais flexível de dar boot em sistemas UEFI.

System administrators who desire to take a minimalist, although more rigid, approach to booting the system can avoid secondary bootloaders and boot the Linux kernel as an EFI stub.

Lembre-se que o pacote sys-boot/efibootmgr não é um gerenciador de boot, mas uma ferramenta para interagir com o firmware UEFI e atualizar suas configurações, assim o kernel Linux que foi previamente instalado pode ser inicializado com opções adicionais (se necessário), ou para permitir múltiplas entradas de boot. Essa interação é feita através das variáveis EFI (por isso a necessidade do suporte do kernel às variáveis EFI).

Certifique-se de ler completamente o artigo EFI stub kernel antes de continuar. O kernel deve ter habilitadas opções específicas para ser bootável pelo firmware UEFI do sistema. Pode ser necessário recompilar o kernel. É também uma boa ideia dar uma olhada no artigo sobre o efibootmgr.

It is also a good idea to take a look at the efibootmgr article for additional information.

Nota
Reiterando, o efibootmgr não é requerido para inicializar um sistema UEFI. O kernel do Linux pode (e é) inicializado imediatamente, e opções de linha de comando do kernel adicionais podem ser embutidas pelo kernel do Linux em si (existe uma configuração do kernel que permite ao usuário especificar os parâmetros de boot). Mesmo um initramfs pode ser feito parte do próprio kernel.

Aqueles que decidiram por seguir este caminho necessitam instalar o software:

FILE /etc/portage/package.accept_keywords/installkernel

sys-kernel/installkernel
sys-boot/uefi-mkconfig
app-emulation/virt-firmware

FILE /etc/portage/package.use/installkernel

sys-kernel/installkernel efistub

Then reinstall installkernel, create the /efi/EFI/Gentoo directory and reinstall the kernel:

root #emerge --ask sys-kernel/installkernel

root #mkdir -p /efi/EFI/Gentoo

For distribution kernels:

root #emerge --ask --config sys-kernel/gentoo-kernel{,-bin}

For manually managed kernels:

root #make install

Depois, crie o diretório /boot/efi/boot/ e então copie o kernel nesse local, chamando-o bzImage.efi:

root #mkdir -p /boot/efi/boot

root #cp /boot/vmlinuz-* /boot/efi/boot/bzImage.efi

Install the efibootmgr package:

root #emerge --ask sys-boot/efibootmgr

Depois, diga ao firmware UEFI que uma entrada de boot chamada "Gentoo" deve ser criada, que contém o pseudo kernel EFI recém instalado:

root #efibootmgr --create --disk /dev/sda --part 2 --label "Gentoo" --loader "\efi\boot\bzImage.efi"

Nota
O uso da \ como separador de diretórios é obrigatório quando usamos as definições UEFI.

Se um sistema de arquivo inicial em RAM (initramfs) deve ser usado, adicione a opção de boot apropriada para ele:

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l "\efi\boot\bzImage.efi" initrd='\initramfs-genkernel-amd64-6.6.21-gentoo'

Dica
Additional kernel command line options may be parsed by the firmware to the kernel by specifying them along with the initrd=... option as shown above.

Com essas alterações feitas, quando o sistema reiniciar, uma entrada de boot chamada "Gentoo" estará disponível.

Unified Kernel Image

If installkernel was configured to build and install unified kernel images. The unified kernel image should already be installed to the EFI/Linux directory on the EFI system partition, if this is not the case ensure the directory exists and then run the kernel installation again as described earlier in the handbook.

To add a direct boot entry for the installed unified kernel image:

root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader "\EFI\Linux\gentoo-x.y.z.efi"

Other Alternatives

For other options that are not covered in the Handbook, see the full list of available bootloaders.

Reiniciando o sistema

Saia do ambiente chroot e desmonte todas as partições montadas. Então digite o comando mágico que dá início ao verdadeiro teste final: reboot.

root #exit

cdimage ~#cd

cdimage ~#umount -l /mnt/gentoo/dev{/shm,/pts,}

cdimage ~#umount /mnt/gentoo{/boot,/sys,/proc,}

cdimage ~#reboot

Claro, não esqueça de remover o CD de boot ou o sistema irá reinicializar pelo CD em vez do novo sistema Gentoo.

Uma vez reiniciado o sistema no ambiente recém-instalado finalize com Finalizando a instalação do Gentoo.

← Instalando as ferramentas Home Finalizando →