Come reinstallare GRUB2 EFI?

• 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/ in modo che efibootmgr non fallisca in seguito. L'avvio con la prima opzione mi dà il seguente errore:

• chroot nel sistema rotto (simile all'aiuto ubuntu grub2 ma con le specificità efi):

• A seconda della vostra distribuzione linux, ora fate cose diverse.

• Ora digitare Ctrl+D per uscire da chroot, smontare tutto e riavviare:

Potrebbe essere necessario adattare questo sistema alle proprie esigenze (tabella delle partizioni diversa, partizione separata /boot, ecc.) e potrebbe non essere l'unica opzione, ma per me ha funzionato benissimo.

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

Come per 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 qualsiasi cosa che avrei fatto per aggiornare-grub o cambiare qualsiasi disco rigido nel server avrebbe causato il mancato avvio. Il sistema operativo nel mio caso è linuxmint-201403-mate-dvd-64bit installato via USB. (vedi sotto per una descrizione completa degli eventi che farebbero sì che l'UEFI non funzioni)

Eseguire esattamente gli stessi passi su un ThinkServer TS140 non ha fatto sì che l'UEFI perdesse la testa neanche una volta. Guardando la pagina dei driver RD430, il mio bios è vecchio di due versioni. Non ho mai dovuto aggiornare il bios su una scheda madre prima d'ora, quindi non sono uno che si aggiorna automaticamente quando ci sono nuove versioni disponibili. Dopo aver aggiornato il bios, la risposta di Maxine ha funzionato, solo con una torsione…

# 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 comando efibootmgr -c ha aggiunto due voci 0000 e 0002! La voce Boot0002* Linux HD prima in ordine di avvio non è corretta. La voce 0000 è corretta.

Per testare questo, ho provato ad avviare senza interruzioni, che è la voce 0002. Come previsto, non ha funzionato. Così 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 le voci 0001 e 0002. L'opzione 0001 è stata l'ultimo dei miei numerosi tentativi di recuperare il sistema operativo.

Note UEFI

Se state leggendo questo e siete frustrati con l'UEFI come lo sono stato io, ecco alcune note e risorse: “ L'avvio su UEFI Shell è simile all'uso di una shell DOS. ” Intel ha fatto un manuale di riferimento PDF per i comandi della shell efi .
“ Il documento di Lenovo UEFI_on_TS430 document è l'unica risorsa che ho visto spiegare l'uso della shell efi. ” Un altro riferimento alla shell uefi da nPartition Administrator’s Guide. “ Si può provare ad avviare una partizione dalla shell efi navigando verso il caricatore ed eseguendola.
” UEFI vuole che il disco abbia una tabella delle partizioni GPT, non una tabella delle partizioni msdos. “ UEFI vuole che la prima partizione del disco sia formattata in fat32 o vfat. ” Per un avvio “generico” ci deve essere una directory /EFI/boot nella root con bootx64.efi. “ Alcune persone copiano il loro grubx64.efi da dove è stato installato su /EFI/boot/bootx64.efi e questo trucco ha funzionato per loro.
” Ogni volta che fate dei cambiamenti di grub, usate efibootmgr -v prima e dopo per assicurarvi che il vostro riavvio sia ok.

La mia esperienza con l'RD430

Ho resinato il sistema operativo più di 10 volte nell'ultima settimana cercando di risolvere questo problema e di configurare il server. La mia configurazione è un SSD su questo controller RAID nello slot PCIe 2.0 con LMDE installato su di esso. AOC-S3008L-L8i controller RAID rimesso in modalità IT ) nel secondo slot PCIe 3.0 con unità da 6x 3TB. RAM: 12GB ECC (3x 4GB).

Ecco le modifiche che farei che causano il mancato avvio del mio sistema: “ Cambiare gli slot pci S3008L-L8i pci (lasciando solo la scheda SSD+card).
” Disattivare il prompt LSi software raid bios del software per il controller di bordo. “ Aggiungere la mia vecchia scheda HighPoint RocketRaid ad uno slot PCIe aperto. ” Fare una modifica a /etc/default/grub e poi eseguire update-grub. (forse grub-install deve essere eseguito anche &007?)

Io lo farei votare, ma a quanto pare non ho abbastanza reputazione su SuperUser. Sono contento di aver finalmente trovato una risposta a questo dopo giorni di lotta contro i cloni che ha funzionato ma non ha funzionato. Penso che tutto sia legato all'UEFI e a qualche tipo 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-efi e grub-efi-amd64 alla 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 - cambiare come appropriato per la distro e l'architettura), e mettere 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

Avviare la chiavetta USB Live, aprire un terminale, eseguire il comando, e il lavoro è un buon ‘un! L'unico problema occasionale è che l'UEFI a volte è stato spostato in basso nell'ordine di priorità di avvio sotto l'HDD, a quel punto è necessario andare nel BIOS e cambiare l'ordine di avvio per fermarlo provando (e fallendo) su SATA: drive.

Si può anche usare dpkg-reconfigure invece di dpkg -i, ma questo pone un paio di domande sul boot loader.

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

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

• creare cartella

• montare la partizione “Sistema EFI” in /etc/fstab

• installare grub-efi-amd64-bin e disinstallare grub-efi-ia32-bin

• riavviare Ubuntu in modalità efi

• verificare se si avvia bene, poi ho installato grub-efi-amd64 e disinstallato grub-pc grub-gfxpayload-lists con

ho scelto di non rimuovere /boot quando richiesto.

Forse ho complicato le cose e questo avrebbe funzionato bene:

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

Questa voce va più nella direzione di preparare il vostro computer per reinstallare le voci efi. È anche quello che si potrebbe 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 reso possibile la mia installazione e ha reso possibile il salvataggio in un secondo momento. E’ nato dal mio desiderio di avere una USB live con persistenza, e dato che il tempo di installare un'utilità come Unetbootin per un'installazione persistente è più o meno lo stesso di una nuova installazione, ho semplicemente usato la stessa distribuzione live per fare un'installazione sulla USB come è stato usato per installare il sistema operativo sull'SSD interno.

Naturalmente, niente di tutto questo è RAID o qualsiasi altra installazione specializzata, ma ha richiesto una partizione di volume preparata sul drive USB, e un'installazione fatta su quella USB usando il metodo disponibile della distro, aggirando il drive interno per un'installazione su una singola partizione di root (/) mount.

Qui è dove la nuova installazione di grub si è aggrovigliata con il drive interno. Quando ho riavviato sulla USB, le voci di grub interne UEFI sembravano essere scomparse, lasciando solo il menu di grub quando si cercava di selezionare il drive usando le voci del menu del BIOS.

Invece, l'avvio dalla USB ha mostrato che il metodo della distro aveva prodotto un menu di grub già pronto, con un elenco per il /dev/sda2, la partizione contenente il mount /boot/efi. Nella maggior parte dei drive interni primari installa il nome della partizione grub è hd0, gpt1.

Entrando in ‘advanced’, era disponibile più di un salvataggio del kernel. Da lì, eseguire l'utilità grub e poi avviare normalmente.

Da questo punto, eseguendo il sistema operativo sul disco interno che prima era inaccessibile, scollegare la USB, quindi eseguire sudo grub-install.

Quando si riavvia senza la USB, si dovrebbe essere in grado di tornare indietro. A questo punto la USB è configurata per lanciare il drive interno in modalità normale o di salvataggio, e il drive ha un proprio menu.