Jak ponownie zainstalować GRUB2 EFI?

Po udanej aktualizacji mojego biosu coś poszło nie tak i skończyło się miganiem kursora w lewym górnym rogu czarnego ekranu. Bez błędów, bez niczego. W biosie wymieniono teraz tylko SATA: <disc name>opcję rozruchu zamiast zwykłej UEFI ubuntu. Korzystam ze schematu partycjonowania GPT.

W końcu odkryłem, że działającym rozwiązaniem była poprawna ponowna instalacja grub-efi-amd64. Jak mam to zrobić?

PS: W rzeczywistości udało mi się ponownie zainstalować GRUB2 EFI i opublikuję tutaj swoją odpowiedź, ponieważ nie byłem w stanie znaleźć kompletnego poradnika na ten temat.

• Uruchom komputer z Live-USB / CD w trybie UEFI . Miałem dwie opcje rozruchu <flash_drive>i UEFI: <flash_drive>potrzebny jest drugi narażać zmienne EFI w /sys/firmware/efi/tak, aby efibootmgrnie zawieść później. Uruchamianie za pomocą pierwszej opcji powoduje następujący błąd:

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

  modprobe efivars nie działało dla mnie.

• chroot do zepsutego systemu (podobny do pomocy Ubuntu grub2, ale ze specyfiką 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
  

• W zależności od dystrybucji Linuksa robisz teraz różne rzeczy.

  • W przypadku Ubuntu / Debian :

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

    lub alternatywnie:

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

    powyższe powinno dać ci gruba, ale nie bootowalnego
    
    

  • W przypadku Fedory (do 16, może działać dla innych):

    yum reinstall grub-efi
    

    W poniższym poleceniu musisz zastąpić sdX urządzeniem, które ma partycję EFI, z której chcesz uruchomić komputer. W --part Ymusisz zastąpić Y numerem partycji EFI (jak w /dev/sdXY).

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

• Teraz naciśnij Ctrl + D, aby wyjść z chroota, odmontuj wszystko i uruchom ponownie:

  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
  

Być może będziesz musiał dostosować to do swoich potrzeb (inna tablica partycji, osobna partycja / boot boot itp.) I może to nie być jedyna opcja, ale dla mnie to zadziałało.

Odpowiednim systemem do naprawiania rzeczy jest grml . Istnieje również obszerny przewodnik na temat konfigurowania rozruchowego urządzenia USB, z którego sekcja Mac jest najbardziej przydatna (wystarczy utworzyć partycję FAT32, skopiować pliki, uruchomić ponownie, gotowe).

Jako potencjalne uproszczenie pierwszej metody, możliwe jest bezpośrednie uruchomienie systemu na dysku twardym, tylko przy użyciu grub płyty CD na żywo. Testowane na Xubuntu 13.10 z Live CD Xubuntu 13.10.

Upewnij się, że bezpieczny rozruch jest wyłączony w systemie BIOS. Włóż płytę CD na żywo i uruchom ją za pośrednictwem UEFI. Wyświetli się menu GRUB na płycie CD. naciśnij „c”, aby przejść do wiersza poleceń.

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

Dostosuj powyższe polecenie grub, jeśli masz inną partycję systemową EFI.

Po uruchomieniu systemu z dysku twardego powinno wystarczyć ponowne zainstalowanie gruba na partycji systemowej EFI i zarejestrowanie go w oprogramowaniu układowym za pomocą grub-install.

sudo grub-install

Podobnie jak w przypadku Maxine, znalazłem ustawienia UEFI w BIOS-ie, aby ulec uszkodzeniu i mój komputer nie chce się uruchomić.

W moim przypadku jest to Lenovo ThinkServer RD430 z systemem Linux Mint Debian i wydawało mi się, że wszystko , co zrobiłbym z aktualizacją grub lub zmianą dysków twardych na serwerze, spowoduje, że nie uruchomi się. System operacyjny w moim przypadku to linuxmint-201403-mate-dvd-64bit zainstalowany przez USB. (patrz poniżej pełny opis zdarzeń, które mogą spowodować, że UEFI nie będzie działać)

Wykonanie dokładnie tych samych kroków na ThinkServer TS140 nie spowodowało, że UEFI straciło rozum nawet raz. Przejrzałem stronę sterownika RD430, a moje biografie mają dwie wersje. Nigdy wcześniej nie musiałem aktualizować biografii na płycie głównej, więc nie jestem osobą, która aktualizuje się automatycznie, gdy będą dostępne nowe wersje. Po zaktualizowaniu biografii powyższa odpowiedź Maxine zadziałała, tylko z niespodzianką ...

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

efibootmgr -cKomenda dodaje dwa wpisy 0000i 0002! Pierwszy wpis w kolejności rozruchu nie jest prawidłowa . Wpis jest prawidłowy.
Boot0002* Linux HD
0000

Aby to przetestować, próbowałem uruchomić komputer bez żadnych zakłóceń, co jest 0002wpisem. Zgodnie z oczekiwaniami nie zadziałało. Ponownie uruchomiłem serwer, nacisnąłem F12 i wybrałem linuxmint. Zgodnie z oczekiwaniami, uruchomił się w mojej instalacji LMDE.

Sposobem na usunięcie niechcianych wpisów za pomocą efibootmgr jest:

# efibootmgr -b 2 -B

Użyłem tego polecenia, aby usunąć wpisy 0001i 0002. Opcja 0001była z ostatniej z moich wielu prób odzyskania systemu operacyjnego.

Uwagi UEFI

Jeśli czytasz to i jesteś tak sfrustrowany UEFI, jak ja / ja, oto kilka notatek i zasobów:
»Uruchamianie w UEFI Shell jest podobne do używania powłoki DOS.
»Firma Intel opracowała podręcznik PDF dla poleceń powłoki efi .
» Dokument UEFI_on_TS430 Lenovo jest jedynym zasobem, jaki widziałem wyjaśniającym użycie powłoki efi.
» Kolejne odniesienie do powłoki uefi z Przewodnika administratora nPartition .
»Możesz spróbować uruchomić system z partycji EFI na partycji, przechodząc do modułu ładującego i uruchamiając go.
»UEFI chce, aby dysk miał tablicę partycji GPT, a nie tablicę części msdos.
»UEFI chce sformatować pierwszą partycję na dysku fat32 lub vfat.
»W przypadku„ ogólnego ”rozruchu musi znajdować się /EFI/bootkatalog w katalogu głównym bootx64.efi.
»Niektóre osoby kopiują swoje pliki grubx64.efiz miejsca, w którym zostały zainstalowane /EFI/boot/bootx64.efii ten kod działał na ich korzyść.
»Za każdym razem, gdy wprowadzasz zmiany grub, użyj efibootmgr -vprzed i po, aby upewnić się, że ponowne uruchomienie jest prawidłowe.

Moje doświadczenie RD430

W ostatnim tygodniu ponownie instalowałem system operacyjny 10+ razy, próbując rozwiązać ten problem i skonfigurować serwer. Moja konfiguracja to dysk SSD na tym kontrolerze RAID w gnieździe PCIe 2.0 z zainstalowanym LMDE. Kontroler RAID AOC-S3008L-L8i (ponownie ustawiony na tryb IT ) w drugim gnieździe PCIe 3.0 z napędami 6x 3 TB. RAM: 12 GB ECC (3 x 4 GB).

Oto zmiany, które wprowadziłbym, które spowodowały, że mój system nie uruchomił się:
»Zmień sloty Sci S832L-L8i pci (pozostawiając samą kartę SSD +).
»Wyłącz monit o bios raid oprogramowania LSi dla wbudowanego kontrolera.
»Dodaj moją starą kartę HighPoint RocketRaid do otwartego gniazda PCIe.
»Wprowadź zmiany, /etc/default/gruba następnie uruchom update-grub.
( może też grub-installtrzeba uruchomić? )

Głosowałbym za tym, ale najwyraźniej nie mam wystarczającej liczby przedstawicieli SuperUser. Cieszę się, że w końcu znalazłem odpowiedź na to po dniach walki z klonami, które działały, ale nie chciały się uruchomić. Myślę, że wszystko to dotyczy UEFI i pewnego rodzaju mechanizmu „bezpiecznego rozruchu” czy coś w tym rodzaju.

Pracuję w trybie off-line, więc apt-get nie wchodziło w grę. To, co zrobiłem, to umieszczenie Ubuntu Desktop na pamięci USB, dodanie pakietów grub-efii grub-efi-amd64do katalogu głównego pamięci USB (grub-efi_1.99 ~ rc1-13ubuntu3_amd64.deb i grub-efi-amd64_1.99 ~ rc1-13ubuntu3_amd64.deb dla Ubuntu 11.04 - zmień odpowiednio dla dystrybucji i architektury), a także umieść następujące elementy w skrypcie na pamięci 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

Uruchom pamięć USB na żywo, otwórz terminal, uruchom polecenie, a zadanie jest dobre! Jedynym sporadycznym problemem jest to, że UEFI czasami przenosiło się w dół kolejności uruchamiania niższej niż HDD, w którym to momencie należy przejść do BIOS-u i zmienić kolejność rozruchu, aby zatrzymać próbę (i niepowodzenia) włączenia SATA: drive.

Możesz także użyć dpkg-reconfigurezamiast dpkg -i, ale to zadaje kilka pytań dotyczących modułu ładującego.

[edytuj] Nie mam też wystarczającej liczby przedstawicieli, aby móc komentować, więc to, co uważałem za komentarz do odpowiedzi, okazuje się odpowiedzią.

Na moim 32-bitowym Ubuntu 14.10 na Lenovo Yoga 2 Pro zmieniłem na rozruch UEFI w następujący sposób:

• utwórz folder

  sudo su
  mkdir /boot/efi
  

• zamontuj partycję „System EFI” w /etc/fstab

  fdisk -l|grep EFI
  

  to pokazało: /dev/sda2 2050048 2582527 532480 260M EFI System

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

  zamontuj tę partycję

  mount /boot/efi
  

• zainstaluj grub-efi-amd64-bini odinstalujgrub-efi-ia32-bin

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

• uruchom ponownie Ubuntu w trybie efi

  update-grub
  

• Test czy buty w porządku, potem zainstalować grub-efi-amd64i odinstalować grub-pc grub-gfxpayload-listsz

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

Na żądanie nie wybieram usuwania / uruchamiania.

Może to skomplikowałem, a to po prostu działałoby dobrze:

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

Ten wpis jest bardziej podobny do przygotowania komputera do ponownej instalacji wpisów efi. To również może być skuteczny i prosty sposób na utworzenie dysku ratunkowego po instalacji systemu na nośniku wewnętrznym (SSD, HDD).

W przypadku Linux Mint Tara (wariant Linuksa ściśle związany z Ubuntu Bionic Beaver) metoda ta zarówno zawiodła moją instalację, jak i umożliwiła jej późniejsze zapisanie. Powstało z mojego pragnienia trwałego USB na żywo, a ponieważ czas instalacji narzędzia takiego jak Unetbootin do instalacji trwałej jest mniej więcej taki sam jak świeża instalacja, po prostu użyłem tej samej dystrybucji na żywo, aby przeprowadzić instalację na USB jako został użyty do zainstalowania systemu operacyjnego na wewnętrznym dysku SSD.

Oczywiście nic z tego nie jest RAID ani żadną inną wyspecjalizowaną konfiguracją, ale wymagało to przygotowanej partycji woluminowej na dysku USB i instalacji wykonanej na tym USB za pomocą dostępnej metody dystrybucji, obchodząc wewnętrzny dysk do instalacji na jednym mocowanie katalogu głównego (/) partycji.

To tutaj nowa instalacja gruba zaplątała się w wewnętrzny dysk. Po ponownym uruchomieniu na USB wydawało się, że wewnętrzne wpisy GRUB UEFI zniknęły, pozostawiając tylko menu GRUB podczas próby wyboru napędu za pomocą wpisów w menu BIOS.

Zamiast tego, uruchomienie z USB pokazało, że metoda dystrybucji stworzyła gotowe menu grub, z listą dla / dev / sda2, partycji zawierającej mount / boot / efi. W większości podstawowych instalacji wewnętrznego dysku nazwa GRUB-a partycji to hd0, gpt1.

Przechodząc do „zaawansowanych”, dostępnych było więcej niż jedno narzędzie ratowania jądra. Następnie uruchom narzędzie Grub, a następnie uruchom normalnie.

Od tego momentu, uruchamiając system operacyjny na wewnętrznym dysku, który wcześniej był niedostępny, odłącz USB, a następnie uruchom sudo grub-install.

Po ponownym uruchomieniu bez USB powinieneś być w stanie wrócić. W tym momencie USB jest skonfigurowany do uruchamiania wewnętrznego napędu w trybie normalnym lub ratunkowym, a napęd ma własne menu.