Come reinstallare GRUB2 EFI?

Dopo aver aggiornato con successo il mio BIOS, qualcosa è andato storto e ho finito con un cursore lampeggiante nell'angolo in alto a sinistra di uno schermo nero. Nessun errore, niente di niente. Il BIOS ora elencava solo SATA: <disc name>un'opzione di avvio al posto della solita UEFI ubuntu. Sto usando uno schema di partizionamento GPT.

Alla fine ho scoperto che la soluzione funzionante era reinstallare correttamente grub-efi-amd64. Quindi, come posso fare?

PS: In realtà, sono riuscito a reinstallare GRUB2 EFI da solo e pubblicherò la mia risposta qui perché non sono stato in grado di trovare alcuna procedura completa su questo.

• Avviare il computer con un live-USB / CD in modalità UEFI . Avevo due opzioni di avvio <flash_drive>e UEFI: <flash_drive>, la seconda è necessaria per esporre le variabili efi in /sys/firmware/efi/modo da efibootmgrnon fallire in seguito. L'avvio con la prima opzione mi dà il seguente errore:

  Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
  Try 'modprobe efivars' as root.
  

  modprobe efivars non ha funzionato per me.

• chroot nel sistema rotto (simile alla guida di Ubuntu grub2 ma con specificità efi):

  sudo mount /dev/sda2 /mnt #sda2 is the root partition
  sudo mount /dev/sda1 /mnt/boot/efi #sda1 is the efi partition
  for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
  sudo cp /etc/resolv.conf /mnt/etc/ #makes the network available after chrooting
  modprobe efivars # make sure this is loaded
  sudo chroot /mnt
  

• A seconda della tua distribuzione Linux, ora fai cose diverse.

  • Per Ubuntu / Debian :

    apt-get install --reinstall grub-efi-amd64
    

    o in alternativa:

    apt-get install --reinstall grub-efi
    update-grub
    

    se quanto sopra ti dà un grub, ma non uno avviabile
    
    

  • Per Fedora (fino a 16 anni, può funzionare per altri):

    yum reinstall grub-efi
    

    Nel comando seguente, è necessario sostituire sdX con il dispositivo con la partizione EFI da cui si desidera avviare. In --part Ydevi sostituire il Y con il numero della partizione EFI (come in /dev/sdXY).

    efibootmgr -c --disk /dev/sdX --part Y
    efibootmgr -v # verify a new record called Linux is there
    

• Ora digita Ctrl + D per uscire da chroot, smonta tutto e riavvia:

  for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
  sudo umount /mnt/boot/efi #please do this. Corrupted efi partitions are not nice
  sudo umount /mnt
  sudo reboot
  

Potrebbe essere necessario adattarlo alle tue esigenze (tabella delle partizioni diverse, partizione separata / di avvio, ecc.) E potrebbe non essere l'unica opzione, ma questo ha funzionato bene per me.

Un sistema live adatto per sistemare le cose è grml . C'è anche una guida estesa su come configurare un dispositivo USB avviabile, di cui la sezione Mac è effettivamente la più utile (basta creare una partizione FAT32, copiare i file, riavviare, fatto).

Come potenziale semplificazione del primo metodo, è possibile avviare direttamente il sistema sul disco rigido, usando solo grub del CD live. Testato su xubuntu 13.10 con il CD live di xubuntu 13.10.

Assicurarsi che l'avvio protetto sia disabilitato nel BIOS. Inserire il CD live e avviarlo tramite UEFI. Verrà visualizzato il menu GRUB del CD. il Premere "c" per accedere alla riga di comando.

configfile (hd0,gpt1)/EFI/ubuntu/grub.cfg

Adattare il comando grub sopra se si dispone di una diversa partizione di sistema EFI.

Dopo che il sistema è stato avviato dal disco rigido, dovrebbe essere sufficiente reinstallare grub sulla partizione di sistema EFI e registrarlo con il firmware tramite grub-install.

sudo grub-install

Come con Maxine, ho trovato le mie impostazioni UEFI nel BIOS danneggiate e la mia macchina non si avviava.

Nel mio caso, è un Lenovo ThinkServer RD430 con Linux Mint Debian e sembrava che tutto ciò che avrei fatto sull'aggiornamento-grub o sulla modifica di qualsiasi disco rigido nel server gli avrebbe impedito l' avvio. Il sistema operativo nel mio caso è linuxmint-201403-mate-dvd-64bit installato tramite USB. (vedi sotto per una descrizione completa degli eventi che potrebbero impedire al UEFI di funzionare)

Eseguendo esattamente gli stessi passaggi su un ThinkServer TS140 non è stato possibile perdere la testa all'UEFI nemmeno una volta. Ho guardato la pagina del driver RD430 e il mio BIOS ha due versioni precedenti. Non ho mai dovuto aggiornare il BIOS su una scheda madre prima, quindi non sono uno che aggiorna automaticamente quando sono disponibili nuove versioni. Dopo aver aggiornato il BIOS, la risposta di Maxine sopra ha funzionato, solo con una svolta ...

# efibootmgr -c --disk /dev/sdX --part Y
# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0002,0000,0003,0001,0004
Boot0000* linuxmint HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\EFI\linuxmint\grubx64.efi)
Boot0001* LMDE Linux Mint Debian    HD(1,800,15d505800,934c598c-fe3c-fd43-84a1-fa38e4f72552)File(\EFI\linuxmint\grubx64.efi)
Boot0002* Linux HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\elilo.efi)
Boot0003* UEFI: Built-in EFI Shell  Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO
Boot0004* UEFI: VerbatimSTORE N GO 1.00 ACPI(a0341d0,0)PCI(1a,0)USB(1,0)USB(4,0)HD(1,80,1d70780,00000000)AMBO
mint / # 

Il efibootmgr -ccomando ha aggiunto due voci 0000e 0002!
La Boot0002* Linux HDvoce prima nell'ordine di avvio non è corretta .
La 0000voce è corretta

Per provare questo, ho provato l'avvio senza alcuna interruzione, che è la 0002voce. Come previsto, non ha funzionato. Quindi ho riavviato il server, ho premuto F12 e ho scelto linuxmint. Come sperato, si è avviato alla mia installazione LMDE.

Il modo per rimuovere le voci indesiderate tramite efibootmgr è:

# efibootmgr -b 2 -B

Ho usato questo comando per rimuovere voci 0001e 0002. L'opzione è 0001stata dall'ultimo dei miei numerosi tentativi di ripristinare il sistema operativo.

Note UEFI

Se stai leggendo questo e frustrato con UEFI come lo sono / ero, ecco alcune note e risorse:
»L'avvio a UEFI Shell è simile all'utilizzo di una shell DOS.
»Intel ha realizzato un manuale di riferimento PDF per i comandi della shell efi .
»Il documento UEFI_on_TS430 di Lenovo è l'unica risorsa che ho visto che spiega l'utilizzo della shell efi.
» Un altro riferimento alla shell uefi dalla Guida dell'amministratore di nPartition .
»Puoi provare ad avviare una partizione dalla shell efi accedendo al caricatore ed eseguendolo.
»UEFI desidera che il disco abbia una tabella delle partizioni GPT, non una tabella delle parti msdos.
»UEFI desidera che la prima partizione sul disco sia formattata fat32 o vfat.
»Per un avvio" generico "deve esserci una /EFI/bootdirectory nella radice con bootx64.efidentro.
»Alcune persone copiano il loro grubx64.efida dove è stato installato /EFI/boot/bootx64.efie questo trucco ha funzionato per loro.
»Ogni volta che apporti modifiche grub, usa efibootmgr -vprima e dopo per assicurarti che il riavvio sia corretto.

La mia esperienza RD430

Ho reinstallato il sistema operativo 10+ volte nella scorsa settimana cercando di risolvere il problema e impostare il server. La mia configurazione è un SSD su questo controller RAID nello slot PCIe 2.0 con LMDE installato su di esso. Controller RAID AOC-S3008L-L8i ( riflesso in modalità IT ) nel 2 ° slot PCIe 3.0 con 6 unità da 3 TB. RAM: 12 GB ECC (3x 4 GB).

Ecco alcune modifiche che farei per
impedire l' avvio del mio sistema: »Modifica degli slot PCI S3008L-L8i (lasciando sola la scheda SSD +).
»Disabilitare il prompt del BIOS RAID software LSi per il controller integrato.
»Aggiungi la mia vecchia scheda RocketRaid HighPoint a uno slot PCIe aperto.
»Apporta una modifica /etc/default/grube quindi esegui update-grub.
( forse grub-installdeve essere eseguito anche tu? )

Voterei questo voto, ma a quanto pare non ho abbastanza rappresentante su SuperUser. Sono contento di aver finalmente trovato una risposta a questo dopo giorni di combattimenti tra cloni che funzionavano ma che non si avviavano. Penso che tutto riguardi UEFI e una sorta di meccanismo di "avvio sicuro" o qualcosa del genere.

Sto lavorando off-line, quindi apt-get non era un'opzione. Quello che ho fatto è stato mettere Ubuntu Desktop su una chiavetta USB, aggiungere i pacchetti grub-efie grub-efi-amd64alla radice della chiavetta USB (grub-efi_1.99 ~ rc1-13ubuntu3_amd64.deb e grub-efi-amd64_1.99 ~ rc1-13ubuntu3_amd64.deb per Ubuntu 11.04 - cambia come appropriato per la distribuzione e l'architettura) e inserisci anche quanto segue in uno script sulla chiavetta USB:

#! /bin/bash
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
dir=`dirname $0`
sudo cp $dir/grub-efi*.deb /mnt/tmp
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb"
sudo shutdown -r now

Avvia la chiavetta USB Live, apri un terminale, esegui il comando e il lavoro è una buona cosa! L'unico problema occasionale è che a volte UEFI è stato spostato verso il basso nell'ordine di priorità di avvio sotto l'HDD, a quel punto è necessario accedere al BIOS e modificare l'ordine di avvio per impedirne il tentativo (e il fallimento) SATA: drive.

Puoi anche usare dpkg-reconfigureinvece di dpkg -i, ma questo pone un paio di domande sul boot loader.

[modifica] Inoltre non ho abbastanza rappresentante per commentare, quindi quello che pensavo fosse un commento su una risposta risulta essere una risposta.

Sul mio Ubuntu 14.10 a 32 bit su Lenovo Yoga 2 Pro, sono passato all'avvio UEFI in questo modo:

• creare una cartella

  sudo su
  mkdir /boot/efi
  

• montare la partizione "EFI System" in /etc/fstab

  fdisk -l|grep EFI
  

  questo ha mostrato: /dev/sda2 2050048 2582527 532480 260M EFI System

  echo "/dev/sda2 /boot/efi   vfat    defaults,sync   0   0">>/etc/fstab
  

  montare quella partizione

  mount /boot/efi
  

• installa grub-efi-amd64-bine disinstallagrub-efi-ia32-bin

  aptitude install grub-efi-amd64-bin grub-efi-ia32-bin_
  
  grub-install --target=x86_64-efi
  

• riavviare Ubuntu in modalità efi

  update-grub
  

• prova se si avvia bene, quindi ho installato grub-efi-amd64e disinstallato grub-pc grub-gfxpayload-listscon

  aptitude install grub-efi-amd64 grub-pc_ grub-gfxpayload-lists_
  

Ho scelto di non rimuovere / avviare quando richiesto.

Forse l'ho reso complicato e questo avrebbe funzionato bene:

apt-get install --reinstall grub-efi
update-grub

Questa voce è più simile alla preparazione del computer per reinstallare le voci efi. È anche quello che potresti trovare un modo efficace e semplice per creare un disco di ripristino dopo l'installazione del sistema su supporti interni (SSD, HDD).

Con Linux Mint Tara (una variante di Linux strettamente correlata a Ubuntu Bionic Beaver), il metodo ha risolto il problema con la mia installazione e ha reso possibile in seguito il salvataggio. È nato dal mio desiderio che una USB live avesse persistenza, e poiché il tempo di installare un'utilità come Unetbootin per un'installazione persistente è all'incirca la stessa di una nuova installazione, ho semplicemente usato la stessa distribuzione live per fare un'installazione su USB come è stato utilizzato per installare il sistema operativo sull'SSD interno.

Naturalmente, nulla di tutto ciò è RAID o qualsiasi altra configurazione specializzata, ma richiedeva una partizione di volume preparata sull'unità USB e un'installazione eseguita su quell'USB usando il metodo disponibile della distribuzione, aggirando l'unità interna per un'installazione su un singolo mount root (/) della partizione.

Qui è dove la nuova installazione di grub si è aggrovigliata con l'unità interna. Quando ho riavviato l'USB, le voci grub UEFI interne sembravano essere scomparse, lasciando solo il menu grub quando si tenta di selezionare l'unità utilizzando le voci nel menu BIOS.

Invece, l'avvio da USB ha mostrato che il metodo della distro aveva prodotto un menu Grub già pronto, con un elenco per / dev / sda2, la partizione contenente il mount / boot / efi. Nella maggior parte delle installazioni di unità interne primarie il nome grub della partizione è hd0, gpt1.

Andando in "avanzato", era disponibile più di un salvataggio del kernel. Da lì, esegui l'utility grub e avvia normalmente.

Da questo punto, eseguendo il sistema operativo sull'unità interna che in precedenza era inaccessibile, scollegare l'USB, quindi eseguire sudo grub-install.

Quando si riavvia senza USB, si dovrebbe essere in grado di rientrare. A questo punto l'USB è configurato per avviare l'unità interna in modalità normale o di salvataggio e l'unità ha il proprio menu.