Handbook:X86/Blocks/Bootloader
Wybór programu rozruchowego
Z skonfigurowanym jadrem Linuksa, zainstalowanymi narzędziami systemowymi i z zmodyfikowanymi plikami konfiguracyjnymi, przyszedł czas na instalację ostatniej ważnej części systemu Linux: systemu rozruchowego.
System rozruchowy jest odpowiedzialny za uruchomienie jądra systemu Linux podczas startu komputera - bez niego, komputer nie wiedziałby co należy zrobić po wciśnięciu przycisku zasilania.
Dla x86, udokumentowaliśmy jak skonfigurować zarówno GRUB2 jak i LILO dla systemów opartych o BIOS, oraz GRUB2 i efibootmgr dla systemów UEFI.
W tej sekcji Podręcznika dokonano podziału pomiędzy "emerge" systemu rozruchowego, a "instalacją" systemu rozruchowego na dysk systemowy. Pojęcie "emerge" będzie używane do zapytania Portage o utworzenie pakietu oprogramowania dostępnego dla systemu. Pojęcie "instalacja" będzie oznaczało kopiowanie plików systemu rozruchowego lub fizyczną modyfikację stosownych sekcji dysku systemowego, w celu "uaktywnienia i przygotowania do działania" systemu rozruchowego na następne uruchomienie systemu operacyjnego.
Domyślnie: GRUB2
Domyślnie, większość systemów Gentoo korzysta teraz z GRUB2 (znajdującego się w pakiecie sys-boot/grub), który jest sukcesorem przestarzałego GRUB. Bez dodatkowej konfiguracji, GRUB2 wspiera starsze wersje BIOS. Z drobną konfiguracją, niezbędną przed kompilacją pakietu, GRUB2 może wspierać więcej niż tuzin dodatkowych platform sprzętowych. Więcej informacji znajdziesz w sekcji Wymagania wstępne artykułu GRUB2.
Emerge
Podczas korzystania z starszego BIOS, system wspiera jedynie tablicę partycji MBR. Nie ma potrzeby dodatkowej konfiguracji w celu zainstalowania systemu rozruchowego GRUB:
root #emerge --ask --verbose sys-boot/grub:2
Informacja dla użytkowników UEFI: uruchomienie powyższej komendy wyświetli aktualną zawartość GRUB_PLATFORMS przed przystąpieniem do kompilacji. Użytkownicy systemów UEFI muszą zapewnić włączenie opcji GRUB_PLATFORMS="efi-64" (jak ma to miejsce domyślnie). Jeżeli opcja nie jest włączona, GRUB_PLATFORMS="efi-64" musi zostać dodane do pliku /etc/portage/make.conf przed przystąpieniem do kompilacji GRUB2, tak aby pakiet był skompilowany z funkcjonalnością EFI:
root #echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf
root #emerge --ask sys-boot/grub:2
- Jeżeli GRUB2 został jakkolwiek skompilowany bez włączenia
GRUB_PLATFORMS="efi-64", linia ta (jak wyżej wskazano) nadal może zostać dodana do pliku make.conf, a zależności zbioru pakietów world ponownie obliczone poprzez użycie opcji--update --newusedla polecenia emerge:
root #emerge --ask --update --newuse --verbose sys-boot/grub:2
Oprogramowanie GRUB2 zostało właśnie przyłączone do systemu, ale nie zostało jeszcze zainstalowane.
Instalacja
Następnie, zainstaluj niezbędne pliki GRUB2 do ścieżki /boot/grub/ poprzez komendę grub-install. Zakładając, że pierwszy dysk (ten z którego system się uruchamia) to /dev/sda, uruchom jedno z poniższych poleceń:
- Podczas korzystania z BIOS:
root #grub-install /dev/sda
For DOS/Legacy BIOS systems:
root #grub-install /dev/sdaPodczas korzystania z UEFI:
- Ważne
Upewnij się, że partycja systemowa EFI została zamontowana przed uruchomieniem grub-install. Istnieje ryzyko, że grub-install zainstaluje plik GRUB EFI (grubx64.efi) w złej ścieżce bez podania jakiegokolwiek wskazania, że użyto złej ścieżki
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
The sys-boot/grub package does not recognize the secureboot USE flag, this is because the GRUB EFI executable is not installed by the package but is instead built and installed by the grub-install command. GRUB must therefore be manually signed after installation to the boot partition. Additionally, GRUB is a modular bootloader but loading modules is prohibited when Secure Boot is enabled. Therefore all necessary modules must be compiled into the GRUB EFI executable, below an example is shown including some basic modules, this may have to be adjusted for more advanced configurations:
root #emerge --noreplace sbsigntoolsroot #export GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo"root #grub-install --target=x86_64-efi --efi-directory=/efi --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csvroot #sbsign /efi/EFI/GRUB/grubx64.efi --key /path/to/kernel_key.pem --cert /path/to/kernel_key.pem --out /efi/EFI/GRUB/grubx64.efiTo 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:
root #emerge sys-boot/shim sys-boot/mokutil sys-boot/efibootmgrroot #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/GRUB/shimx64.efiroot #cp /usr/share/shim/mmx64.efi /efi/EFI/GRUB/mmx64.efiShims MOKlist requires keys in the DER format, since the OpenSSL key generated in the example here is in the PEM format, the key must be converted first:
root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DERThe 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.derAnd 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\GRUB\shimx64.efi' --label 'shim' --unicodeDebugging 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.
- Ważne
Jeśli grub-install zwraca błąd podobny doCould not prepare Boot variable: Read-only file system, może być konieczne ponowne zamontowanie efivars w trybie do odczytu i zapisu, aby odnieść sukces:root #mount -o remount,rw /sys/firmware/efi/efivars
root #mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivarsThis 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.
Some motherboard manufacturers with poor UEFI implementations seem to only support the /EFI/BOOT directory location for the .EFI file in the EFI System Partition (ESP). The GRUB installer can create the .EFI file in this location automatically by appending the --removable option to the install command. Ensure the ESP has been mounted before running the following command; presuming it is mounted at /efi (as defined earlier), run:
root #grub-install --target=x86_64-efi --efi-directory=/boot --removableThis creates the 'default' directory defined by the UEFI specification, and then creates a file with the default name: bootx64.efi.
Konfiguracja
Next, generate the GRUB configuration based on the user configuration specified in the /etc/default/grub file and /etc/grub.d scripts. In most cases, no configuration is needed by users as GRUB will automatically detect which kernel to boot (the highest one available in /boot/) and what the root file system is. It is also possible to append kernel parameters in /etc/default/grub using the GRUB_CMDLINE_LINUX variable.
Aby wygenerować końcową konfigurację GRUB2, uruchom polecenie grub-mkconfig:
root #grub-mkconfig -o /boot/grub/grub.cfgGenerating grub.cfg ... Found linux image: /boot/vmlinuz-6.6.21-gentoo Found initrd image: /boot/initramfs-genkernel-x86-6.6.21-gentoo done
The output of the command must mention that at least one Linux image is found, as those are needed to boot the system. If an initramfs is used or genkernel was used to build the kernel, the correct initrd image should be detected as well. If this is not the case, go to /boot/ and check the contents using the ls command. If the files are indeed missing, go back to the kernel configuration and installation instructions.
The os-prober utility can be used in conjunction with GRUB to detect other operating systems from attached drives. Windows 7, 8.1, 10, and other distributions of Linux are detectable. Those desiring dual boot systems should emerge the sys-boot/os-prober package then re-run the grub-mkconfig command (as seen above). If detection problems are encountered be sure to read the GRUB article in its entirety before asking the Gentoo community for support.
Alternatywa 1: LILO
Emerge
LILO, the LInuxLOader, is the tried and true workhorse of Linux boot loaders. However, it lacks features when compared to GRUB. LILO is still used because, on some systems, GRUB does not work and LILO does. Of course, it is also used because some people know LILO and want to stick with it. Either way, Gentoo supports both bootloaders.
Instalacja LILO to pestka; wystarczy użyć emerge.
root #emerge --ask sys-boot/liloKonfiguracja
Aby skonfigurować LILO, najpierw utwórz plik /etc/lilo.conf:
root #nano -w /etc/lilo.confIn the configuration file, sections are used to refer to the bootable kernel. Make sure that the kernel files (with kernel version) and initramfs files are known, as they need to be referred to in this configuration file.
If the root filesystem is JFS, add an
append="ro" line after each boot item since JFS needs to replay its log before it allows read-write mounting./etc/lilo.confExample LILO configurationboot=/dev/sda # Install LILO in the MBR
prompt # Give the user the chance to select another section
timeout=50 # Wait 5 (five) seconds before booting the default section
default=gentoo # When the timeout has passed, boot the "gentoo" section
compact # This drastically reduces load time and keeps the map file smaller; may fail on some systems
image=/boot/vmlinuz-6.6.21-gentoo
label=gentoo # Name we give to this section
read-only # Start with a read-only root. Do not alter!
root=/dev/sda3 # Location of the root filesystem
image=/boot/vmlinuz-6.6.21-gentoo
label=gentoo.rescue # Name we give to this section
read-only # Start with a read-only root. Do not alter!
root=/dev/sda3 # Location of the root filesystem
append="init=/bin/bb" # Launch the Gentoo static rescue shell
# The next two lines are for dual booting with a Windows system.
# In this example, Windows is hosted on /dev/sda6.
other=/dev/sda6
label=windows
Jeśli używany jest inny schemat partycjonowania i/lub obraz jądra, dostosuj go odpowiednio.
Jeśli initramfs jest konieczny, zmień konfigurację, odwołując się do tego pliku initramfs i informując initramfs, gdzie znajduje się urządzenie root:
/etc/lilo.confDodawanie informacji o initramfs do wpisu rozruchowego'"`UNIQ--pre-00000007-QINU`"'
If additional options need to be passed to the kernel, use an append statement. For instance, to add the video statement to enable framebuffer:
/etc/lilo.confAdding video parameter to the boot optionsimage=/boot/vmlinuz-6.6.21-gentoo
label=gentoo
read-only
root=/dev/sda3
append="video=uvesafb:mtrr,ywrap,1024x768-32@85"
Users that used genkernel should know that their kernels use the same boot options as is used for the installation CD. For instance, if SCSI device support needs to be enabled, add doscsi as kernel option.
Teraz zapisz plik i wyjdź.
Instalacja
To finish up, run the /sbin/lilo executable so LILO can apply the /etc/lilo.conf settings to the system (i.e. install itself on the disk). Keep in mind that /sbin/lilo must be executed each time a new kernel is installed or a change has been made to the lilo.conf file in order for the system to boot if the filename of the kernel has changed.
root #/sbin/liloAlternative 2: efibootmgr
Computer systems with UEFI-based firmware technically do not need secondary bootloaders (e.g. GRUB) in order to boot kernels. Secondary bootloaders exist to extend the functionality of UEFI firmware during the boot process. Using GRUB (see the prior section) is typically easier and more robust because it offers a more flexible approach for quickly modifying kernel parameters at boot time.
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.
The sys-boot/efibootmgr application is a tool to used interact with UEFI firmware - the system's primary bootloader. Normally this looks like adding or removing boot entries to the firmware's list of bootable entries. It can also update firmware settings so that the Linux kernels that were previously added as bootable entries can be executed with additional options. These interactions are performed through special data structures called EFI variables (hence the need for kernel support of EFI vars).
Ensure the EFI stub kernel article has been reviewed before continuing. The kernel must have specific options enabled to be directly bootable by the UEFI firmware. It may be necessary to recompile the kernel in order to build-in this support.
It is also a good idea to take a look at the efibootmgr article for additional information.
To reiterate, efibootmgr is not a requirement to boot an UEFI system; it is merely necessary to add an entry for an EFI-stub kernel into the UEFI firmware. When built appropriately with EFI stub support, the Linux kernel itself can be booted directly. Additional kernel command-line options can be built-in to the Linux kernel (there is a kernel configuration option called CONFIG_CMDLINE. Similarly, support for initramfs can be 'built-in' to the kernel as well. These decisions must be made prior to kernel compilation, resulting in a more static boot configuration.
Install the efibootmgr software:
root #emerge --ask sys-boot/efibootmgrCreate the /efi location, and copy the kernel into this location, calling it bootx64.efi:
root #mkdir -p /efi
root #cp /boot/vmlinuz-* /efi/bootx64.efi
The use of a backslash (\) as directory path separator is mandatory when using UEFI definitions.
Create boot entry called "gentoo" for the freshly compiled EFI stub kernel within the UEFI firmware:
root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader "\bootx64.efi"Jeśli używany jest inicjalny system plików RAM (initramfs), dodaj do niego odpowiednią opcję rozruchu:
root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l "\efi\boot\bootx64.efi" initrd='\initramfs-genkernel-x86-6.6.21-gentoo'Note that the above command presumes an initramfs file was copied into the ESP inside the same directory as the bootx64.efi file.
With these changes done, when the system reboots, a boot entry called "gentoo" will be available.
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/EFI/Linux/gentoo-x.y.z.efiAlternative 3: Syslinux
Syslinux is yet another bootloader alternative for the x86 architecture. It supports MBR and, as of version 6.00, it supports EFI boot. PXE (network) boot and lesser-known options are also supported. Although Syslinux is a popular bootloader for many it is unsupported by the Handbook. Readers can find information on emerging and then installing this bootloader in the Syslinux article.
Alternative 4: 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.
To install systemd-boot:
root #bootctl installMake 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 listIf no new entry exists, ensure the sys-kernel/installkernel package has been installed with the systemd-boot USE flag enabled, and re-run the kernel installation.
For the distribution kernels:
root #emerge --ask --config sys-kernel/gentoo-kernelFor a manually configured and compiled kernel:
root #make installWhen 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 automatically. 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. A postinst hook to automatically update systemd-boot and set it up with shim instead is provided on the systemd-boot wiki page. However the first time this should be done manually by following the steps below:
root #emerge --ask sys-boot/shim sys-boot/mokutil sys-boot/efibootmgrroot #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/BOOT/BOOTX64.EFIroot #cp /usr/share/shim/mmx64.efi /efi/EFI/BOOT/mmx64.efiroot #cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/BOOT/grubx64.efiShim is hardcoded to load grubx64.efi. As such the systemd-boot bootloader must be named as if it were GRUB.
Shims MOKlist requires keys in the DER format, since the OpenSSL key generated in the example here is in the PEM format, the key must be converted first:
root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DERThe 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.derAnd 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\BOOT\BOOTX64.EFI' --label 'shim' --unicode