Handbook:AMD64/Blocks/Bootloader/it

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:AMD64/Blocks/Bootloader and the translation is 8% complete.
Outdated translations are marked like this.


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

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.

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.

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

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

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

Install the efibootmgr package:

root #emerge --ask sys-boot/efibootmgr

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"
Nota
L'uso di \ come separatore di cartelle è obbligatorio quando si usano le definizioni UEFI.

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'
Suggerimento
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.

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


Retrieved from "https://wiki.gentoo.org/index.php?title=Handbook:AMD64/Blocks/Bootloader/it&oldid=1352397"