Perché la maggior parte delle distribuzioni concatena UEFI e grub?

La maggior parte delle distribuzioni installa un caricatore di avvio aggiuntivo su un sistema UEFI. Lo stesso UEFI è un caricatore di avvio, offre un menu per selezionare diversi sistemi operativi o singoli kernel. Inoltre, le impostazioni UEFI possono essere facilmente modificate con strumenti come userspace efibootmgr.

I kernel dalla 3.3 supportano EFI_STUB, il che significa che il kernel può essere caricato direttamente dall'UEFI. Qual è il motivo per cui le distribuzioni decidono di utilizzare un boot loader aggiuntivo? La maggior parte dei tutorial su Linux / UEFI si concentra principalmente su come impostare il boot loader aggiuntivo (rEFInd, grub2, ELILO, ecc.) Invece di avviare Linux con EFI_STUB.

L'unica cosa che manca nelle distribuzioni è il supporto. Poiché la maggior parte delle distribuzioni concatenano un secondo caricatore di avvio, il kernel non viene aggiunto al menu di avvio UEFI, né viene copiato nella partizione di sistema EFI.

Tre script sono sufficienti per fare tutta la magia. Uno che copia gli initramfs su ESP. Un secondo copia il kernel su ESP e crea una nuova voce nel menu di avvio UEFI. Il terzo script rimuove il vecchio kernel e initramfs dall'ESP ed elimina la voce del menu di avvio UEFI. Ciò consente aggiornamenti / eliminazioni completamente automatici del kernel / initramfs senza l'interazione dell'utente. Sto usando questo approccio da più di un anno e ha funzionato perfettamente.

Perché la maggior parte delle distribuzioni utilizza grub invece di EFI_STUB?

link:

• Come ricreare la partizione di avvio EFI?

EDIT: Non sto parlando di rimuovere completamente il supporto grub, ma di offrire una scelta a coloro che vogliono usarlo per vari motivi. Le distribuzioni potrebbero fornire un pacchetto grub-efiper coloro che vogliono concatenare UEFI e grub e un pacchetto efistub-bootche contiene gli script che ho menzionato sopra.

Dato che l'UEFI è stata definita solo nel 2005, esiste un mucchio di apparecchiature legacy che non supportano le specifiche. L'aggiunta di UEFI a una distribuzione standard richiederebbe il test di due percorsi di codice anziché uno, e non solo il codice di avvio è notoriamente complicato, ma è uno dei bit di codice più fastidiosamente lunghi da testare.

Le distribuzioni hanno risorse limitate e potrebbero non esserci ragioni al di là di ciò. Può essere ragionevolmente semplice e sicuro, ma a prescindere da ciò che richiederà più interventi di manutenzione perché l'opzione grub deve essere mantenuta, anche se solo per sistemi non UEFI.

Sono sicuro che tutti hanno un elenco di funzionalità e opzioni che vorrebbero vedere adottare le distro (ti darò alcune pagine, lol), e senza dubbio molte di queste sarebbero "totalmente facili, senza problemi, onestamente. .. ". Tuttavia, non vi è una quantità infinita di ore di persona per implementarle. Di fronte a decisioni come questa ("Inseriamo il lavoro in questa funzione, rispetto ad altre?") Le domande principali dovrebbero essere:

• È necessario? (La risposta qui è no).
• Quante persone ne trarranno beneficio e quanto? (IMO: pochi e non molto)
• Esiste un'alternativa ragionevole in base alla quale l'utente può adattarsi senza che noi facciamo nulla? (Apparentemente c'è.)

Il motivo per cui le persone usano le distro è perché tutti sono soggetti a vincoli di risorse (altrimenti, basta assumere una squadra, acquistare un po 'di spazio e attrezzature e far fare tutto per te esattamente come vuoi). Quindi la realtà è che le distro riflettono le esigenze generalizzate dei loro utenti.

Detto questo, penso che questo verrà adottato nel tempo come opzione e ho votato a favore della domanda.

Il targeting dei bootloader UEFI oltre a grub complicherebbe il controllo e il supporto della qualità. Le distro si rivolgono a grub piuttosto che alle specifiche UEFI perché grub è software libero, hackerabile, più flessibile e di alta qualità. Puoi comunque ottenere un avvio puro-UEFI seguendo un tutorial e montando la partizione UEFI /boot, perché se lo fai, la manutenzione è su di te.

Il vero problema è che le persone non capiscono come funziona. Ad esempio, nella tua domanda menzioni che tre script sono tutto ciò che è necessario e che la maggior parte delle risposte qui riguarda tutto / qualsiasi manutenzione aggiuntiva che sarebbe necessaria per farlo funzionare - ma la verità è che non hai bisogno di quegli script o qualsiasi lavoro aggiuntivo.

Tutto ciò di cui hai bisogno è di associare mount ESP - o ovunque tu voglia mantenere il kernel - finito /boot, cosa che puoi fare con una sola riga in/etc/fstab . Fallo e tutti gli attuali script di aggiornamento del kernel continueranno semplicemente a funzionare.

Il mio `/ etc / fstab 'assomiglia a:

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

C'è un buon punto qui, tuttavia, sulle impostazioni specifiche del produttore. UEFI esplicitamente non senza specificare l'interfaccia per un menu di avvio. Questo è in palio e non sarà coerente tra le macchine. È fastidioso, ma vero.

E così, mentre un caricatore come in grubrealtà rende solo più lavoro, un'applicazione di menu - come rEFInd - uniforma le differenze e semplifica tutto.

Incatenano UEFI e GRUB come soluzione di implementazione temporanea.

Man mano che il supporto UEFI e i problemi associati (ad es. Secure Boot) vengono risolti, sempre più distribuzioni lo useranno direttamente. Nel frattempo è ancora molto nuovo: Google Trends mostra un'adozione piuttosto limitata: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & CMPT = q

Altri hanno citato tutte le potenziali insidie ​​di scegliere una soluzione UEFI pura e / o supportare contemporaneamente sistemi non UEFI e sistemi UEFI puri. Un kernel UEFI potrebbe funzionare su un sistema non UEFY, ma gli strumenti di aggiornamento del kernel devono aggiornare un menu GRUB O un menu di avvio UEFI OPPURE entrambi, ecc. Ecc.

Si tratta in realtà del controllo di qualità come menzionato: soprattutto i problemi con questo codice hanno un forte impatto: quando il computer non riesce ad avviare nuovi utenti, ad esempio potenziali convertitori di Linux, lo abbandonerà come spazzatura e tornerà a qualcosa di "sicuro".

Ma come ho detto quando la tecnologia ottiene più adozione diventerà lo standard.

È necessario un codice aggiuntivo per aggirare i bug del firmware

Quando non si esegue il concatenamento di grub, la distribuzione si affida maggiormente al firmware per l'avvio corretto. Poiché qualsiasi software avrà problemi, anche il firmware è incline a questo. Ora le distribuzioni Linux dovranno scrivere per aggirare anche questi bug del firmware.

Un caso di vita reale come esempio. La scheda madre Asrock H81 pro BTC P1.80 consente la creazione di voci del menu di avvio con efibootmgr. Possono essere create più voci del menu di avvio e l'ordine di avvio può essere modificato utilizzando efibootmgr --bootorder XXXX,YYYY,ZZZZoppure è possibile impostare un'opzione di avvio successiva temporanea utilizzando efibootmgr --bootnext XXXX. Entrambi questi comandi restituiscono un output che ti dà l'idea che l'ordine di avvio è cambiato o che il prossimo avvio verrà eseguito, ad esempio BootNext: XXXX. Tuttavia al riavvio il firmware testardo ignora solo l'opzione di avvio appena richiesta e si riavvia nel BootCurrent:valore precedente . Una modifica permanente dell'ordine di avvio può essere effettuata solo dall'utility di configurazione del firmware. E un cambiamento non permanente non è affatto disponibile.

Penso che se l'avvio viene eseguito solo da EFI e rimuoviamo il bootloader, sarà difficile sia per i produttori di sistemi hardware che per i produttori di sistemi operativi. Il fornitore di HW avrà più kernel da testare mentre per le aziende che producono SO, sarà come se il loro kernel fosse caricato da FW diversi.

Inoltre, con l'avvio diretto del kernel da EFI, dove si adatterà l'avvio sicuro nello stack? Nello scenario attuale, una volta che il controllo passa al bootloader del sistema operativo, quindi il bootloader verifica se il kernel è firmato correttamente o meno. Nel caso in cui cariciamo il kernel direttamente da EFI, penso che creerà confusione solo quando l'intero stack verrà disturbato. Solo un'opinione da quale comprensione ho.