Hoe installeer je GRUB2 EFI?

• Start uw computer op met een live-USB/CD _ in UEFI-modus. Ik had twee boot opties `<flashdrive>enUEFI: , de tweede is nodig om de efi variabelen in/sys/firmware/efi/bloot te leggen zodatefibootmgr` niet later faalt. Het opstarten met de eerste optie geeft me de volgende fout:

• chroot in het gebroken systeem (vergelijkbaar met de ubuntu grub2 help maar met efi specificiteiten):

• Afhankelijk van je linux distributie, doe je nu verschillende dingen.

• Typ nu Ctrl+D om de chroot af te sluiten, alles te ontkoppelen en opnieuw op te starten:

U moet dit misschien aanpassen aan uw behoeften (andere partitietabel, aparte /boot-partitie, etc.) en het is misschien niet de enige optie, maar dit werkte voor mij prima.

Een geschikt live-systeem voor het repareren van dingen is grml . Er is ook een uitgebreide gids over hoe een bootable USB-apparaat te installeren, waarvan de Mac sectie eigenlijk het meest bruikbaar is (gewoon een FAT32-partitie maken, de bestanden kopiëren, herstarten, klaar).

Net als bij Maxine, vond ik mijn UEFI instellingen in BIOS om beschadigd te raken en mijn machine zou niet opstarten.

In mijn geval is het een Lenovo ThinkServer RD430 met Linux Mint Debian en het leek alles ik zou doen aan update-grub of het veranderen van een harde schijf in de server zou ervoor zorgen dat het niet zou opstarten. OS in mijn geval is linuxmint-201403-mate-dvd-64bit geïnstalleerd via USB. (zie hieronder voor een volledige beschrijving van de gebeurtenissen die ervoor zouden zorgen dat UEFI niet werkt)

Het doorlopen van precies dezelfde stappen op een ThinkServer TS140 heeft er niet toe geleid dat UEFI ook maar één keer zijn verstand heeft verloren. Ik heb de RD430 driver pagina bekeken en mijn biografieën zijn twee versies oud. Ik heb nog nooit eerder een bios op een moederbord moeten updaten, dus ik ben niet iemand die automatisch moet updaten als er nieuwe versies beschikbaar zijn. Na het updaten van de bios werkte Maxine’s antwoord hierboven, alleen met een twist…

# 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 / #

Het efibootmgr -c commando voegde twee items 0000 en 0002 toe! De Boot0002* Linux HD entry eerst in bootvolgorde is niet correct. De 0000 entry is correct.

Om dit te testen, probeerde ik het opstarten zonder enige onderbreking, wat de 0002 entry is. Zoals verwacht werkte het niet. Dus ik herstartte de server, drukte op F12, en koos linuxmint. Zoals gehoopt bootte het wel naar mijn LMDE installatie.

De manier om ongewenste invoer via efibootmgr te verwijderen is:

# efibootmgr -b 2 -B

Ik gebruikte dit commando om de invoer 0001 en 0002 te verwijderen. Optie 0001 was van de laatste van mijn vele pogingen om het OS te herstellen.

• *

UEFI notities

Als je dit leest en net zo gefrustreerd bent met UEFI als ik, zijn hier enkele notities en bronnen: “ Opstarten naar UEFI Shell is vergelijkbaar met het gebruik van een DOS-shell. ” Intel maakte een PDF referentiehandleiding voor efi -shellcommando’s.
“ Lenovo’s UEFI_on_TS430 document is de enige bron die ik heb gezien waarin het gebruik van efi-shell wordt uitgelegd. ” Een andere uefi-shell referentie van nPartition Administrator’s Guide. “ U kunt proberen op te starten naar een partitie van de efi-shell door naar de lader te navigeren en deze uit te voeren.
” UEFI wil dat de schijf een GPT partitietabel heeft, niet een msdos partitietabel. “ UEFI wil dat de eerste partitie op uw schijf geformatteerd wordt met fat32 of vfat. ” Voor een “generieke” boot moet er een /EFI/boot map zijn bij de root met bootx64.efi erin. “ Sommige mensen kopiëren hun grubx64.efi van waar het geïnstalleerd was naar /EFI/boot/bootx64.efi en deze cheat werkte voor hen.
” Telkens wanneer je wijzigingen aanbrengt, gebruik je efibootmgr -v voor en na het herstarten om er zeker van te zijn dat het goed is.

• *

Mijn RD430 ervaring

Ik heb het OS 10+ keer opnieuw geïnstalleerd in de afgelopen week om te proberen dit uit te zoeken en de server op te zetten. Mijn configuratie is een SSD op deze RAID-controller in de PCIe 2.0-slot met LMDE erop geïnstalleerd. AOC-S3008L-L8i RAID-controller terugverwezen naar IT-modus ] in de 2de PCIe 3.0-sleuf met 6x 3TB-stations. RAM: 12GB ECC (3x 4GB).

Hier zijn wijzigingen die ik zou aanbrengen waardoor mijn systeem niet opstartte: “ Verander de S3008L-L8i pci-slots (laat de SSD+kaart met rust).
” Schakel de LSi software raid bios prompt uit voor onboard controller. “ Voeg mijn oude HighPoint RocketRaid kaart toe aan een open PCIe slot. ” Maak een wijziging in /etc/default/grub en draai dan update-grub. (_maybe grub-install moet ook worden uitgevoerd? _)

Ik zou dit opvoeren, maar blijkbaar heb ik niet genoeg rep op SuperUser. Ik ben blij dat ik eindelijk een antwoord heb gevonden op dit na dagen van vechten tegen klonen die wel werkten maar niet wilden opstarten. Ik denk dat het allemaal betrekking heeft op UEFI en een soort van “secure booting” mechanisme of zoiets.

Ik werk off-line, dus apt-get was geen optie. Wat ik deed was Ubuntu Desktop op een USB stick zetten, de grub-efi en grub-efi-amd64 pakketten toevoegen aan de root van de USB stick (grub-efi1.99~rc1-13ubuntu3 _amd64.deb en grub-efi-amd641.99~rc1-13ubuntu3 _amd64.deb voor Ubuntu 11. 04 - verandering voor distro en architectuur), en zet ook het volgende in een script op de USB-stick:

#! /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

Start de Live USB-stick op, open een terminal, voer het commando uit, en de klus is een goede ‘un! Het enige incidentele probleem is dat UEFI soms de opstartprioriteitsvolgorde naar beneden werd geschoven onder de HDD, op dat moment moet je in het BIOS gaan en de opstartvolgorde veranderen om het proberen (en falen) op SATA: drive te stoppen.

Je kunt ook dpkg-reconfigure gebruiken in plaats van dpkg -i, maar dat stelt een paar bootloader vragen.

[edit] Ik heb ook niet genoeg rep om commentaar te geven, dus wat ik dacht dat een commentaar op een antwoord was, blijkt een antwoord te zijn.

Op mijn 32 bit Ubuntu 14. 10 op Lenovo Yoga 2 Pro, veranderde ik naar UEFI boot zoals dit:

• maak map

aan - mount “EFI System” partitie in /etc/fstab

• installeer grub-efi-amd64-bin en de-installeer grub-efi-ia32-bin

• reboot Ubuntu in efi mode

• test of het goed opstart, dan installeer ik grub-efi-amd64 en de-installeer grub-pc grub-gfxpayload-lists met

Ik kies ervoor om &007 niet te verwijderen /boot wanneer daarom gevraagd wordt.

• *

Misschien heb ik het ingewikkeld gemaakt en zou dit gewoon goed gewerkt hebben:

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

Dit item ligt meer in de lijn van het voorbereiden van uw computer op het opnieuw installeren van de efi-items. Het is ook wat je zou kunnen vinden als een effectieve en eenvoudige manier om een reddingsschijf te maken na de installatie van het systeem op interne media (SSD, HDD).

Met Linux Mint Tara (een Linux-variant die nauw verwant is aan Ubuntu Bionic Beaver), heeft de methode zowel mijn installatie geborked, als het later mogelijk gemaakt om het op te slaan. Het kwam voort uit mijn wens om een live USB te hebben met persistentie, en aangezien de tijd om een utility als Unetbootin te installeren voor een persistente installatie ongeveer hetzelfde is als een nieuwe installatie, gebruikte ik gewoon dezelfde live-distributie om een installatie op de USB uit te voeren als werd gebruikt om het OS op de interne SSD te installeren.

Natuurlijk is dit geen RAID of een andere gespecialiseerde installatie, maar het vereiste wel een voorbereide volumepartitie op de USB-drive, en een installatie op die USB met behulp van de beschikbare methode van de distro, waarbij de interne drive wordt omzeild voor een installatie op een enkele partitie’s root (/) mount.

Dit is waar de nieuwe grub installatie verstrikt raakt in de interne drive. Toen ik herstartte naar de USB, leken de interne UEFI grub entries te zijn verdwenen, waardoor alleen het grub menu overbleef bij het selecteren van de schijf met behulp van de entries in het BIOS menu.

In plaats daarvan toonde het opstarten vanaf de USB aan dat de distro’s methode een kant-en-klaar grub menu had geproduceerd, met een lijst voor de /dev/sda2, de partitie die de /boot/efi mount bevatte. In de meeste primaire interne schijven is de grub naam van de partitie hd0, gpt1.

In ‘advanced’ gaan, was er meer dan één kernel rescue beschikbaar. Vanaf daar draait u de grub utility en vervolgens start u normaal op.

Vanaf dit punt draait u het OS op de interne schijf die voorheen onbereikbaar was, haalt u de USB stekker eruit en draait u vervolgens sudo grub-install.

Wanneer u herstart zonder de USB, zou u weer in staat moeten zijn om in te stappen. Op dit punt is de USB geconfigureerd om de interne schijf in de normale of reddingsmodus te starten, en de schijf heeft zijn eigen menu.