'' EFI boot partition '' e '' biosgrub ''


21

Perché ho bisogno di questi? Ho installato Ubuntu in un non UEFI (master boot record) e ho installato Ubuntu senza "biosgrub" e funziona bene, mentre altre volte mi viene chiesto di creare una partizione "biosgrub". Non ho idea del perché a volte ne ho bisogno e altri no (entrambi sono stati sullo stesso sistema).

E la stessa cosa succede quando uso UEFI (GUID Partition Table). L'unica differenza è che mi viene chiesto di creare una "partizione di avvio EFI", ma come per il "biosgrub", a volte mi viene chiesto di crearla e altre volte non mi viene richiesto di crearla.

Per la mia installazione attuale mi è stato chiesto di crearne una, ma non l'ho fatto e il mio sistema va bene. Non ci sono cambiamenti nel sistema, nello stesso hardware, nel BIOS ecc ... Qualcuno potrebbe far luce su questo?


2
Devi essere coerente nell'avvio. Solo se nella modalità di avvio UEFI avrai bisogno della partizione efi e solo nella modalità di avvio BIOS con partizionamento gpt avrai bisogno della partizione bios_grub. Se si utilizza UEFI, ma avviare Boot-Repair in modalità BIOS e provare a installare grub in modalità BIOS, verrà richiesto di creare una partizione bios_grub.
oldfred

Risposte:


34

Esistono quattro condizioni (BIOS vs. EFI e MBR vs. GPT), ma due hanno esigenze identiche (e una di queste è estremamente rara):

  • Su un computer tradizionale basato su BIOS con una tradizionale tabella delle partizioni MBR, il codice eseguibile di GRUB si diffonde come gli spaghetti lanciati da un bambino. Alcuni si trovano nella sezione del codice di avvio dell'MBR, altri nei settori post-MBR ufficialmente non allocati e altri nella /bootpartizione Linux . Questo è un vero casino e funziona solo perché gli sviluppatori hanno avuto letteralmente decenni per creare hack intelligenti e risolvere (quasi) tutti i nodi.
  • Su un computer tradizionale basato su BIOS con una nuova GUID Partition Table (GPT), il codice GRUB è simile a quello del caso precedente; tuttavia, i settori immediatamente successivi all'MBR non sono non allocati; sono usati dallo stesso GPT. GPT non offre un posto analogo per il dirottamento di GRUB, quindi gli sviluppatori di GRUB si sono basati sulla partizione di avvio del BIOS (che GParted e partedidentificata da un bios_grubflag) per contenere il codice che andrebbe nei settori post-MBR su un disco MBR. Questo è in realtà più sicuro e più pulito dell'approccio MBR, poiché serve a proteggere il codice GRUB da altri programmi che potrebbero tentare di utilizzare quello spazio non allocato.
  • Su un computer con un EFI più recente anziché un BIOS, i caricatori di avvio non sono memorizzati nell'MBR, nei settori post-MBR non allocati ufficialmente o nelle partizioni di avvio del BIOS; invece, i bootloader risiedono come file ordinari su una partizione FAT nota come EFI System Partition (ESP) . (In modo confuso, gli installatori Debian e Ubuntu si riferiscono all'ESP con il nome "EFI partizione di avvio", ma questo nome non è standard. GParted e partedidentifica l'ESP come se avesse "bootflag ", sebbene la terminologia significhi qualcosa di completamente diverso sui dischi MBR.) Un ESP può esistere su un disco GPT o su un disco MBR, ma il primo è molto più comune sui computer basati su EFI. L'approccio EFI è molto più sicuro e molto più flessibile dell'approccio BIOS, poiché non ripone il codice raw in luoghi strani; i caricatori di avvio risiedono in file, proprio come i programmi a livello di sistema operativo. Ciò li rende più facili da identificare e manipolare. (OTOH, EFI memorizza anche i dati sui boot loader in NVRAM, che crea un secondo punto di errore nel processo di avvio. La novità di EFI significa anche che non è così ben testato, il che spiega una serie di problemi specifici di EFI.)

GhostMotleyX, il tuo commento alla risposta di LiveWireBT affermato che il modo "migliore" per installare è BIOS / MBR. Questo è soggettivo, ovviamente, ma non sono d'accordo con tale valutazione. L'approccio BIOS / MBR è il meno sicuro e il più goffa dei tre approcci che ho appena delineato. L'approccio EFI è l'approccio più sicuro e flessibile. Ho il sospetto che ti stia rompendo il fatto che sono necessarie partizioni separate per gli approcci GRUB / GPT ed EFI, ma non è un grosso problema. A parte quando si configura il sistema o si esegue la manutenzione delle partizioni, queste partizioni saranno praticamente invisibili per te e ti daranno molta flessibilità. A differenza di MBR, GPT non si limita a quattro partizioni primarie, quindi non è necessario accumulare le tue partizioni primarie come un leprechaun che accumula il suo oro.


Grazie a tutti coloro che hanno risposto, informazioni davvero utili; soprattutto Rod Smith.
GhostMotleyX,

Quindi su un sistema di avvio EFI, hai ancora bisogno di una piccola partizione? Il settore di avvio MBR e i EF02contenuti (o equivalenti) della partizione gdisk (o equivalenti) possono essere memorizzati in file nella partizione di sistema EFI formattata FAT (con tipo gdisk EF00)?
Peter Cordes,

Peter, sì, è sostanzialmente corretto; I caricatori di avvio EFI sono file memorizzati sull'ESP, non nei settori di avvio del disco o della partizione.
Rod Smith

E se mi piacerebbe supportare sia l' avvio UEFI sia l' avvio BIOS? Avrei quindi due copie di grub, una EFI System Partitionnell'altra e l'altra nella BIOS boot partition?
Ciao World

Ciao mondo, avresti bisogno di un caricatore di avvio in modalità EFI e in modalità BIOS. Non devono essere entrambi GRUB. In effetti, raccomando che almeno uno di loro non lo sia, dal momento che potrebbe diventare piuttosto confuso. Una configurazione del genere è piuttosto inutile per l'avvio di un singolo sistema operativo, tuttavia. Potrebbe essere necessario per alcuni scenari a doppio avvio, ad esempio se un sistema operativo non dispone di un caricatore di avvio in modalità EFI e l'altro deve avviarsi in modalità EFI per qualche motivo (ad esempio, se si tratta di Windows e il disco è superiore a 2 TB, quindi avresti bisogno di GPT per supportare le sue dimensioni complete).
Rod Smith,

7

È necessario creare una partizione biosgrub su un disco partizionato GPT quando si configura l'avvio legacy o una partizione di avvio EFI (sia per il disco partizionato GPT o MBR) quando si avvia l'avvio UEFI.

  • GRUB richiede una partizione di avvio del BIOS (2 MiB, nessun filesystem, EF02codice di tipo in gdisk o flag bios_grub in GNU Parted) nei sistemi BIOS per incorporare il suo core.imgfile a causa della mancanza di gap di incorporamento post-MBR nei dischi GPT . [...]

https://wiki.archlinux.org/index.php/GPT#Bootloader_Support


1
Grazie, penso di aver capito adesso; se sto installando Ubuntu non UEFI su un disco MBR non avrò bisogno di biosgrub. Se installo Ubuntu sotto UEFI su un disco GPT, allora devo creare una partizione EFI. E poi l'incoerenza che stavo riscontrando era quando avrei installato Ubuntu non UEFI su un disco GPT e anche UEFI con MBR. Quindi il modo migliore in teoria per installare Ubuntu è Non UEFI con tabella delle partizioni MBR o UEFI con tabella delle partizioni GPT.
GhostMotleyX,

@GhostMotleyX È corretto.
LiveWireBT

anche 1MiB è più che sufficiente. Mi piace metterlo davanti alla prima "normale" partizione allineata a 1MiB, come ho spiegato nell'ultimo paragrafo di en.wikipedia.org/wiki/BIOS_boot_partition#Overview (che ho appena modificato). Non ho deciso se preferirei utilizzare il sortcomando gdisk per rinumerare le partizioni in ordine di avvio del settore o se desidero lasciarlo come sdc4o w / e. Probabilmente l'ordinamento è meno strano, quindi le mie partizioni grub lo saranno sempre sdX1.
Peter Cordes,

3

Darò un ulteriore punto / motivo per avere entrambi, EFI e BIOS GRUB.

Chiavetta USB per avviare un loop Live SystemRescueCD.iso da Grub2.

Perché? Risposta semplice: si avvierà su molti PC, alcuni hanno UEFI alcuni hanno solo BIOS a 32 bit, ecc.

Motivo davvero complesso: utilizzare l'hardware avanzato (UEFI) se possibile.

Esempio di utilizzo live reale:

  • Chiavetta USB (formattata in modalità GPT) con quattro partizioni
  • Prima partizione (visibile da Windows 7 e versioni successive) su NTFS con le altre dimensioni della chiavetta USB
  • Seconda partizione per il file Grub2 e SystemRescueCD.iso con almeno 1GiB (meglio se 2GiB in modo da poter trasportare due versioni di SystemRescueCD.iso contemporaneamente, solo per testare la nuova versione prima di sostituire quella precedente), normalmente uso il filesystem Ext4 per questo
  • Terza partizione per EFI (che Windows chiama ESP) formattata come Fat32 con almeno 512 MiB (ho visto alcuni PC che se usano meno non mostrano la chiavetta USB come supporto di avvio)
  • Quarta partizione per BIOS_Grub (nessun formato, ma cancellato quando creato)

Una cosa importante: ho visto un LG USB stric da 8GiB (uno che possiedo) che rifiuta di essere elencato su un avvio PC UEFI fisico se le partizioni non sono allineate ai cilindri, ma sono visibili su altri PC UEFI e anche su VirtualBOX con avvio UEFI modalità attivata ... durante il partizionamento se allineato a MiB, utilizza tutto lo spazio, non c'è spazio vicino a 1MiB non partizionato alla fine, ma quando allineato ai cilindri non viene utilizzato l'ultimo MiB incompleto ... se faccio il partizionamento MiB tenendo presente questo (in altre parole faccio un allineamento manuale del cilindro) funziona, ma come sto dicendo è ancora allineato al cilindro (lo sto facendo manualmente invece di lasciare che lo strumento di partizionamento lo faccia per te).

Come ottenere una grande chiavetta USB di recupero (ha due trucchi):

  1. Allinea le partizioni ai cilindri (migliore compatibilità per allinearsi semplicemente al MiB)
  2. Esegui un grub-install --target = i386-pc e poi esegui un altro grub-install --target = x86_64-efi sulla stessa partizione grub, quindi usi solo un grub.cfg per entrambe le modalità di avvio

Come si avvia:

  • a) l'avvio dal vecchio BIOS, caricherà MBR, quindi Stage2 di grub dalla partizione BIOS_grub, quindi core.img dalla partizione Grub2
  • b) l'avvio da UEFI compatibile, caricherà il file .efi dalla partizione ESP
  • viene letto grub.cfg (se esiste sulla partizione grub2)
  • quindi viene visualizzato il menu grub2
  • quindi seleziono l'avvio dal loop SystemRescueCD.iso (con parametro dochace), ho impostato due opzioni impostate su grub.cfg, una per 32 bit, una per 64 bit (ho davvero quattro opzioni, dato che ho impostato due su un parametro dostartx su avvio direttamente sulla GUI).
  • dopo l'avvio posso espellere la chiavetta USB (l'intero Live Linux è in ramdrive grazie a tale docache), non è necessario digitare alcun comando, pendrive non è montato (di nuovo grazie al parametro docache).

Con questa chiavetta posso avviare il vecchio PC (se consentono l'avvio da USB) a 32 bit o anche 64 bit (se hanno estensione etend sul processore), ma avviando in modalità BIOS.

Con questo stick posso anche avviare un nuovo PC (se consentono l'avvio da USB) a 32 e 64 bit, ma avviando in modalità UEFI (ah, sì, può avviarsi in modalità UEFI e quindi avviare Linux Live SystemRescueCD a 32 bit modalità e in modalità 64 bit).

Quindi ho tutto in un supporto di avvio di ripristino della chiavetta USB, in grado di avviarsi in quasi tutti i PC, moderni o vecchi (necessita solo del supporto di avvio USB), non importa se a 32 bit o 64 bit, BIOS o UEFI, ecc ... e posso seleziona quello che voglio eseguire 32 bit o 64 bit.

Inoltre, avevo testato su un PC che si rifiuta di installare Windows 64 bit (vecchio processore 32 bit), ma essere in grado di eseguire un Linux Live a 64 bit (perché la capacità PAE esiste su quel processore).

Nota a margine: tale prima partizione come NTFS è per contenere i dati che possono essere condivisi con Windows 7 e versioni successive (XP non lo vedrà poiché non supporta il partizionamento GPT) ... deve essere il primo, non è necessario essere sull'iniziale parte del disco, può essere ovunque tu voglia, ma Push risiede come prima voce nella tabella delle partizioni, questo è causato dalla modalità Windows hatable per montare le partizioni su rimovibili, ha un codice specificamente programmato per evitare di accedere più della prima partizione, quindi tu non è possibile montare gli altri contemporaneamente.

Extra per Windows e partizioni USB: se si scambiano le voci delle partizioni sulla tabella partitiong, in altre parole si inserisce la partizione a cui si desidera accedere come la prima nella tabella, Windows consente di accedervi (se il suo formato è compreso, fat32 e NTFS direttamente, ext2 con driver speciali, ecc.), ma consentirà solo l'accesso a quello che si trova sulla prima voce della tabella delle partizioni ... esiste uno strumento (chiamato BootICEx86.exe) che può fare tale lavoro su Windows senza nemmeno bisogno di scollegare la chiavetta USB.

Super extra: ci sono anche alcuni pendrive (sono molto fortunato a possederne uno, un Sony 16GiB) che può essere modificato un po 'con strumenti speciali (il mio con uno strumento di lexar) in modo che appaiano a Windows come un HDD USB anziché una chiavetta USB , dopo tale modifica, tutte le finestre ti consentiranno di eliminare, creare e gestire le partizioni su di essa, inoltre è possibile montarne più di una contemporaneamente, ognuna con la propria lettera.

Gli utenti di Linux non si preoccupano di ciò, dal momento che Linux lo vede come un dispositivo a blocchi partizionabile e non implementa un codice speciale per bloccare le partizioni di montaggio, ecc., Come ha fatto Windows.

Oh, sì, questi ultimi paragrafi sono scritti nel caso in cui qualcuno su M $ li legga, quindi la loro faccia scenderà a terra, sto provando (non lo capirò mai, so che è un obiettivo perso) per rimuovere tali brutto codice da Windows e consente agli utenti di avere partizioni su chiavetta USB in modo nativo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.