Handbook:AMD64/Blocks/Bootloader/it

Scegliere un avviatore

Con il kernel Linux configurato, gli strumenti di sistema installati ed i file di configurazione modificati, è tempo di installare l'ultimo importante pezzo di un'installazione Linux: l'avviatore (bootloader).

L'avviatore è responsabile del lancio del kernel Linux al momento dell'avvio - senza di esso, il sistema non saprebbe come procedere quando il pulsante di accensione (power) viene premuto.

Per amd64, documenteremo come configurare sia GRUB2 che LILO per sistemi basati su BIOS, e GRUB2 o efibootmgr per sistemi UEFI.

In questa sezione del Manuale, viene fatta una delineazione tra emergere un pacchetto per l'avviatore (boot loader) ed installare un avviatore nel disco di sistema. Qui il termine emergere sarà usato per chiedere a Portage di compilare un pacchetto software che sia disponibile per il sistema. Il termine installare significherà che l'avviatore copia i file o modifica fisicamente le sezioni appropriate dell'unità del disco di sistema affinché l'avviatore sia attivo e pronto ad operare dalla prossima accensione della macchina.

Predefinito: GRUB2

In via predefinita, la maggior parte dei sistemi Gentoo si affidano ora a GRUB2 (presente nel pacchetto sys-boot/grub), che è il diretto successo di GRUB Legacy. Senza configurazioni aggiuntive, GRUB2 supporta di buon grado i vecchi sistemi BIOS ("pc"). Con alcune configurazioni, necessarie prima della fase di compilazione, GRUB2 può supportare più di una mezza dozzina di piattaforme aggiuntive. Per maggiori informazioni, consultare la Sezione dei prerequisiti nell'articolo di GRUB2.

Compilare (emergere)

Quando si usano sistemi BIOS più vecchi che supportano solo tabelle delle partizioni MBR, nessuna configurazione aggiuntiva è necessaria per compilare (far emergere) GRUB:

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

Una nota per gli utenti UEFI: eseguire il comando sopra comporterà l'abilitazione dei valori GRUB_PLATFORMS prima del comando emergere. Quando si usano sistemi che supportano UEFI, gli utenti si dovranno assicurare che GRUB_PLATFORMS="efi-64" sia abilitato (così come avviene nel caso predefinito). Se non è questo il caso durante la configurazione, GRUB_PLATFORMS="efi-64" dovrà essere aggiunto al file /etc/portage/make.conf prima di far emergere GRUB2, così che il pacchetto sarà compilato con la funzionalità EFI:

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

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

Se GRUB2 è stato compilato (fatto emergere) senza abilitare GRUB_PLATFORMS="efi-64", la linea (appena mostrata) può essere in seguito aggiunta a make.conf e le dipendenze per il "mondo" dei pacchetti ricalcolati passando le opzioni --update --newuse a emerge:

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

Il software GRUB2 è ora fruibile nel sistema, ma non è ancora installato.

Installare

Poi, installare i file necessari di GRUB2 sulla cartella /boot/grub/ attraverso il comando grub-install. Supponendo che il primo disco (quello da cui il sistema si avvia) sia /dev/sda, uno dei successivi comandi sarà:

• Quando si usa il BIOS:

root #grub-install /dev/sda

For DOS/Legacy BIOS systems:

root #grub-install /dev/sda

• Quando si usa UEFI:

Importante
Assicurarsi che la partizione di sistema EFI sia stata montata, prima di eseguire grub-install. È possibile che grub-install installi il file EFI GRUB (grubx64.efi) nella cartella sbagliata senza fornire alcuna indicazione sulla cartella sbagliata usata.

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 sbsigntools

root #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.csv

root #sbsign /efi/EFI/GRUB/grubx64.efi --key /path/to/kernel_key.pem --cert /path/to/kernel_key.pem --out /efi/EFI/GRUB/grubx64.efi

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:

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

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

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

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 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

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\GRUB\shimx64.efi' --label 'shim' --unicode

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.

If grub-install returns an error that says "Could not prepare Boot variable: Read-only file system", and the live environment was correctly booted in UEFI mode, then it should be possible to remount the efivars special mount as read-write and then re-run the aforementioned grub-install command:

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.

Alcuni produttori di schede madri sembrano supportare soltanto la posizione della cartella /efi/boot/ per i file .EFI nella partizione di sistema EFI (ESP). L'installatore di GRUB può eseguire questa operazione automaticamente con l'opzione --removable. Verificare che ESP sia montata prima di eseguire i seguenti comandi. Supponendo che ESP sia montata su /boot (come suggerito prima), eseguire:

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

Questo crea una cartella predefinita definita dalle specifiche UEFI, e poi copia i file grubx64.efi nella posizione 'predefinita'dei file EFI definita dalle stesse specifiche.

Configurare

Poi, generare la configurazione GRUB2 basata su quella specificata dall'utente nel file /etc/default/grub e negli script /etc/grub.d. Nella maggior parte dei casi, nessuna configurazione è richiesta agli utenti, in quanto GRUB2 rileverà automaticamente quale kernel avviare (quello più in alto disponibile su /boot/) e qual è il file system radice. È anche possibile aggiungere parametri per il kernel su /etc/default/grub tramite la variabile GRUB_CMDLINE_LINUX.

Per generare la configurazione finale di GRUB2, eseguire il comando grub-mkconfig:

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

Generating (Sto generando) grub.cfg ...
Found linux image (Immagine linux trovata): /boot/vmlinuz-6.6.21-gentoo
Found initrd image (Immagine initrd trovata): /boot/initramfs-genkernel-amd64-6.6.21-gentoo
done (fatto)

In risposta il comando deve riferire che almeno un'immagine Linux è stata trovata, in quanto queste sono necessarie per l'avvio del sistema. Se viene utilizzato un initramfs o genkernel è stato usato per compilare il kernel, anche l'immagine initrd corretta dovrebbe essere rilevata. Se questo non succede, andare su /boot/ e controllare il contenuto con il comando ls. Se effettivamente mancano i file, ritornare alla configurazione del kernel ed alle istruzioni di installazione.

Suggerimento
L'utilità os-prober può essere usata in combinazione con GRUB2 per rilevare altri sistemi operativi dai dischi connessi. Windows 7, 8.1, 10 ed altre distribuzioni Linux sono rilevabili. Chi desidera un sistema con doppio avvio dovrebbe compilare il pacchetto sys-boot/os-prober, poi rieseguire il comando grub-mkconfig (come visto sopra). Se si incontrano problemi di rilevamento assicurasi di leggere l'articolo GRUB2 per intero prima di chiedere supporto alla comunità di Gentoo.

Alternativa 1: LILO

Compilare (emergere)

LILO, il LInuxLOader (caricatore di Linux), è il vero cavallo di battaglia degli avviatori di Linux. Comunque, difetta per caratteristiche se comparato a GRUB. LILO è ancora usato, perché su alcuni sistemi GRUB non funziona, mentre LILO sì. Certamente è usato anche perché alcune persone conoscono LILO e vogliono rimanere con esso. Ad ogni modo, Gentoo supporta entrambi gli avviatori (bootloader).

Installare LILO è molto facile; basta usare emerge.

root #emerge --ask sys-boot/lilo

Configurare

Per configurare LILO, creare prima /etc/lilo.conf:

root #nano -w /etc/lilo.conf

Nel file di configurazione, le sezioni vengono utilizzate per fare riferimento al kernel avviabile. Assicurarsi che i file del kernel (con la versione del kernel) e dell'initramfs siano noti, in quanto devono essere indicati in questo file di configurazione.

Nota
Se il file system radice è JFS, aggiungere una linea append="ro" dopo ciascun elemento di avvio poiché JFS deve rieseguire il suo registro prima di consentire il montaggio in lettura e scrittura.

FILE /etc/lilo.confEsempio di configurazione di LILO

'"`UNIQ--pre-00000005-QINU`"'

Nota
Se uno schema di partizionamento e/o un'immagine del kernel differenti sono stati usati, aggiustare in accordo con la propria situazione.

Se è necessario un initramfs, allora cambiare la configurazione facendo riferimento a questo file initramfs e comunicando all'initramfs dove è collocato il dispositivo radice (root):

FILE /etc/lilo.confAggiungere informazioni su initramfs a una voce di avvio

'"`UNIQ--pre-00000008-QINU`"'

Se opzioni aggiuntive devono essere passate al kernel, usare una dichiarazione append. Per esempio, per aggiungere la dichiarazione video per abilitare il framebuffer (segmento di memoria per i fotogrammi):

FILE /etc/lilo.confAggiunta del parametro video alle opzioni di avvio

'"`UNIQ--pre-0000000B-QINU`"'

Gli utenti che hanno usato genkernel dovrebbero sapere che i loro kernel usano le stesse opzioni di avvio usate dal CD di installazione. Per esempio, se il supporto ai dispositivi SCSI deve essere abilitato, aggiungere doscsi come opzione per il kernel.

Adesso salvare il file ed uscire.

Installare

Per concludere, lanciare l'eseguibile /sbin/lilo così che LILO possa applicare le impostazioni /etc/lilo.conf al sistema (vale a dire installa se stesso sul disco). Tener presente che /sbin/lilo deve essere eseguito ogni volta che viene installato un nuovo kernel o quando si modifica il file lilo.conf, così che il sistema possa avviarsi anche se il nome del file del kernel è stato cambiato.

root #/sbin/lilo

Alternativa 2: efibootmgr

Su sistemi UEFI, il firmware UEFI del sistema (in altre parole il principale bootloader - avviatore) può essere manipolato direttamente per cercare le voci di avvio UEFI. Questi sistemi non necessitano di avviatori aggiuntivi (anche conosciuti come avviatori secondari), come GRUB2 allo scopo di aiutare il sistema ad avviarsi. Dopo quanto detto, la ragione degli avviatori basati su EFI come GRUB2 esiste per estendere le funzionalità dei sistemi UEFI durante il processo di avvio. Usare efibootmgr è per coloro che desiderano decisamente mantenere un approccio minimalista (sebbene più rigido) nell'avvio del proprio sistema; usare GRUB2 (vedi sopra) è più facile per la maggior parte degli utenti perché offre un approccio più flessibile quando si avviano i sistemi 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.

Terner presente che l'applicazione sys-boot/efibootmgr non è un avviatore; piuttosto è uno strumento per interagire con il firmware UEFI ed aggiornare le sue impostazioni, così che il kernel Linux precedentemente installato possa essere avviato con opzioni aggiuntive (se necessario), oppure per abilitare più voci di avvio. Questa interazione è possibile grazie alle variabili EFI (da cui la necessità del supporto delle variabili EFI da parte del kernel).

Assicurarsi di leggere l'articolo EFI stub kernel prima di continuare. Il kernel deve avere opzioni specifiche abilitate affinché sia direttamente avviabile dal firmware UEFI del sistema. Potrebbe risultare necessario ricompilare il kernel. È anche una buona idea dare un'occhiata all'articolo efibootmgr.

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

Nota
Per ribadire, efibootmgr non è un requisito di avvio di un sistema UEFI. Il kernel Linux stesso può essere avviato immediatamente, ed opzioni aggiuntive per il kernel tramite linea di comando possono essere integrate nel kernel Linux (c'è un'opzione di configurazione del kernel chiamata che permette agli utenti di specificare i parametri di avvio tramite opzioni a linea di comando). Anche un initramfs può essere 'integrato' nel kernel.

Coloro che hanno deciso di seguire questo approccio devono installare il software:

root #emerge --ask sys-boot/efibootmgr

Poi, creare la cartella /boot/efi/boot/ e copiare qui il kernel, chiamandolo bzImage.efi:

root #mkdir -p /boot/efi/boot

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

Nota
L'uso di \ come separatore di cartelle è obbligatorio quando si usano le definizioni UEFI.

In seguito, comunicare al firmware UEFI che una voce di avvio nominata "Gentoo" deve essere creata, la quale contiene il kernel appena compilato con la parte EFI:

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

Se un file system iniziale su RAM (initramfs) viene usato, aggiungere l'appropriata opzione di avvio ad esso:

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

Note that the above command presumes an initramfs file was copied into the ESP inside the same directory as the bzImage.efi file.

Concluse queste modifiche, quando il sistema si riavvia, sarà disponibile una voce di avvio chiamata "Gentoo".

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.efi

Alternativa 3: Syslinux

Syslinux è un'altra alternativa di bootloader per l'architettura amd64. Supporta MBR e, come da versione 6.00, supporta l'avvio EFI. Anche l'avvio PXE (network) e opzioni meno conosciute sono supportate. Sebbene Syslinux sia un famoso bootloader per molti, non è supportato dal Manuale. I lettori possono trovare informazioni per emergerlo ed installarlo nell'articolo Syslinux.

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 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

If 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-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 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/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/BOOT/BOOTX64.EFI

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

root #cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/BOOT/grubx64.efi

Nota
Shim 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 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

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\BOOT\BOOTX64.EFI' --label 'shim' --unicode