Ho avuto delle esperienze piuttosto negative con GRUB2 . Potrei dire (e ho detto) alcune brutte cose sul suo processo di progettazione e sviluppo. Non mi piacciono particolarmente i suoi mezzi di aggiornamento:per qualsiasi motivo deve aggiornare in modo semiautomatico diversi script – uno indirettamente tramite l'altro in una catena – per ogni aggiornamento del kernel – o molti altri minori (e apparentemente non correlati) modifiche alla configurazione.
Questo è direttamente in contrasto con le precedenti esperienze che ho avuto con LILO – a cui sto seriamente pensando di tornare – poiché non ho mai avuto problemi con esso e la sua configurazione era piuttosto semplice. Tanto per cominciare, a quanto ricordo, dovevo solo aggiornare (o meglio, si aggiornava sempre e solo) un singolo file di testo di configurazione gestito in modo semplice per ogni aggiornamento del kernel.
Quindi, come funziona LILO su hardware moderno con i kernel di oggi? Come funziona GRUB? Come funzionano gli altri bootloader? Devo soddisfare delle precondizioni o si tratta solo di scrivere il file di configurazione ed eseguire lilo comando come lo ricordo con affetto ai vecchi tempi? L'aggiornamento del pacchetto del kernel (Debian/Ubuntu) aggiorna LILO come fa con GRUB2?
Risposta accettata:
ELILO
Gestione dei caricatori di avvio EFI per Linux:utilizzo di ELILO
È davvero difficile per me decidere quale parte di ciò copiare+incollare perché è tutto molto buono, quindi ti chiederò per favore di leggerlo.
Rod Smith
Crea e mantiene entrambi gdisk e rEFInd .
Ma prima di farlo vorrei commentare un po' su di esso. Il link ELILO sopra è a una delle tante pagine sull'avvio UEFI che troverai su rodsbooks.com scritto da Rod Smith. È un abile scrittore tecnico e se hai mai cercato su Google l'argomento dell'avvio UEFI e non hai letto qualcosa di suo, è probabile che tu abbia saltato i primi risultati.
Avvio UEFI Linux
Fondamentalmente, il kernel Linux può essere eseguito direttamente dal firmware.
Nel link sopra menziona lo stub loader EFI del kernel Linux – questo è quello che dovresti usare, secondo me, in quanto consente al kernel Linux di essere chiamato direttamente dal firmware stesso. Indipendentemente da cosa stai facendo qualcosa viene eseguito dal firmware e sembra che qualcosa sia grub . Se il firmware può caricare direttamente il kernel del tuo sistema operativo, a cosa serve un bootloader? Il firmware UEFI monta una partizione GPT formattata FAT contrassegnata esp dalla tabella delle partizioni ed esegue un percorso lì salvato come variabile di avvio UEFI in un modulo di memoria flash integrato. Quindi una cosa che potresti fare è mettere il kernel Linux su quella partizione FAT e memorizzare il suo percorso in quella variabile di avvio. Improvvisamente il kernel è proprio bootloader.
Bootloader
Sui sistemi UEFI, i bootloader sono ridondanti, incluso ELILO.
Il problema che i bootloader sono stati progettati per risolvere era che i sistemi BIOS leggono solo nel primo settore dell'avvio partizione contrassegnata ed eseguirla. È un po' difficile fare qualcosa di significativo con un kernel da 512 byte, quindi la cosa più comune da fare era scrivere una piccola utility che potesse montare un filesystem in cui tenevi l'effettivo kernel e caricarlo a catena.
Correlati:determinare la shell nello script durante il runtime?
Infatti i 512 byte spesso non bastavano nemmeno per i bootloader. grub , ad esempio, in realtà esegue il chainload prima ancora di eseguire il chainload del kernel, perché incunea il suo secondo stadio nello spazio vuoto tra il settore di avvio e il primo settore del tuo filesystem. È una specie di sporco trucco, ma ha funzionato.
Bootmanager
Per semplicità di configurazione, tuttavia, alcuni l'intermediario può essere utile.
Quello che fa rEFInd di Rod Smith è lanciare come un'applicazione EFI – questo è un concetto relativamente nuovo. È un programma che viene eseguito da disco da – e che ritorna – al firmware. Ciò che fa rEFInd è consentire di gestire i menu di avvio e quindi restituire la selezione di avvio al firmware eseguire. Viene fornito con i driver del filesystem UEFI – quindi, ad esempio, puoi usare il caricatore di stub EFI del kernel su un non FAT partizione (come il tuo attuale /boot ). È semplicissimo da gestire, se necessario, e aggiunge la semplicità di un kernel di sistema eseguibile alla comodità di un bootmanager configurabile.
Indirizzamento atomico
Il kernel non ha bisogno di collegamenti simbolici:può mount --bind .
Se è presente un percorso sul tuo / dove dovresti non consentire il collegamento simbolico, è /boot . Un collegamento simbolico orfano in /boot è non il tipo di problema che dovresti mai dover risolvere. Tuttavia, è una pratica abbastanza comune impostare elaborate indirections in /boot da diverse distribuzioni, anche se è un'idea orribile, al fine di gestire aggiornamenti del kernel sul posto e/o configurazioni multiple del kernel.
Questo è un problema per i sistemi EFI non configurato per caricare i driver del filesystem (come quelli forniti con il pacchetto rEFInd) perché FAT è nel complesso un filesystem abbastanza stupido e non li comprende.
Personalmente non utilizzo i driver del filesystem UEFI forniti con rEFInd, sebbene la maggior parte delle distribuzioni includa un pacchetto rEFInd che può essere installato tramite il gestore pacchetti e dimenticato di usare semplicemente il proprio terribile collegamento simbolico /boot config e rEFInd dei driver del filesystem UEFI in pacchetto.
Mia configurazione
Una volta ci ho scritto una serie di istruzioni e l'ho postata qui, ma sembra:
% grep esp /etc/fstab &&
> ls /esp/EFI
LABEL=ESP /esp vfat defaults 0 1
/esp/EFI/arch_root /boot none bind,defaults 0 0
arch_root/ arch_sqsh/ arch_xbmc/ BOOT/ ipxe/
Quindi ho appena inserito quelle due righe nel mio /etc/fstab puntando a una cartella che intendo contenere /boot della nuova installazione di Linux e io sono quasi finito di preoccuparsi di tutto. Devo anche fare:
cat /boot/refind_linux.conf
"Arch" "root=LABEL=data rootflags=subvol=arch_root,rw,ssd,compress-force=lzo,space_cache,relatime"
A parte l'installazione di refind-efi pacchetto tramite pacman per il primo, questo è tutto ciò che è necessario per configurare tutte le installazioni/configurazioni separate che desidero. Nota che la maggior parte di quella stringa sopra è costituita da opzioni di montaggio specifiche per btrfs specificate come parametri del kernel. Un più tipico /boot/refind_linux.conf probabilmente assomiglierebbe a:
"Menu Entry" "root=/dev/sda2"
Ed è tutto ciò che serve.
rodsbooks.com
Se desideri ancora ELILO, puoi trovare le istruzioni per l'installazione al link sopra. Se vuoi rEFInd troverai i link ad esso nel primo paragrafo lì. Fondamentalmente se vuoi eseguire qualsiasi configurazione di avvio UEFI, leggi prima rodsbooks.com.
Correlati:N alternativa a sed che supporta unicode?