Błąd grub: nie znaleziono pliku „/grub/i386-pc/normal.mod”?

Niedawno zainstalowałem arch (mam nadzieję, że pomyślnie) na moim komputerze. Jednak kiedy zrestartowałem komputer, miałem problem. Mam czarny ekran z napisem

Grub loading.
Welcome to GRUB!
error: file '/grub/i386-pc/normal.mod' not found.
Entering rescue mode...
grub rescue>

Od tego czasu szukałem odpowiedzi w Google. Prawie znalazłem jeden tutaj na forach Ubuntu, ale potem zobaczyłem jeden z komentarzy, który powiedział, że to nieprawda. Jest też inna odpowiedź, ale nie jestem pewien, czy chcę zainstalować z Live CD z obawy, że coś popsuję.

Zrozumiałbyś mój strach, gdybyś spędził 7 godzin na konfigurowaniu tego po ciągłym napotykaniu problemów z partycjonowaniem, poleceniami, samouczkami i systemem. Co za radość.

Czy ktoś wie o łatwym rozwiązaniu problemu z działaniem gruba?

Naprawdę denerwująca rzecz ...

Ponieważ najwyraźniej katalog / boot / grub / i386-pc po prostu nie istniał, w końcu rozwiązałem problem, kopiując cały / usr / lib / grub / i386-pc do / boot / grub. To wszystko.

cp -r /usr/lib/grub/i386-pc /boot/grub

Jestem w trakcie podobnego problemu (nawiasem mówiąc, również na łuku)

Grub nie może znaleźć tego pliku i uruchomić go, ponieważ używa niepoprawnego „przedrostka”

Oto co robisz. Uruchamiasz tryb ratowania gruba, a następnie po prostu zastanawiasz się, jak go uruchomić.

Najpierw uruchom zestaw, wyświetli to zmienne, na przykład moja jest

cmdpath=(hd0)
prefix=(hd1,msdos3)/boot/grub
root=hd1,msdos3

Teraz przedrostek jest zmienną, w której grub szuka pliku normal.mod. W moim przypadku hd1, msdos3 jest taki sam jak / dev / sdb3 (podobnie, hd0, msdos1 to / dev / sda1), co możesz chcieć zrobić, aby zobaczyć listę poprawnych partycji, wpisz ls

Teraz, w moim przypadku, ponownie grub został zainstalowany na / dev / sdb1, który został zamontowany jako / boot na mojej partycji arch, więc poprawnym prefiksem będzie (hd1, msdos1) / grub

Aby uruchomić, muszę to zrobić:

set prefix=(hd1,msdos1)/grub
insmod normal
normal

W twoim przypadku będziesz musiał zapamiętać lub zgadnąć, na której partycji zainstalowałeś grub. Możesz zgadnąć źle, nie spowoduje to żadnej szkody, polecenie insmod po prostu się nie powiedzie i możesz spróbować ponownie z inną partycją.

Następnie grub załaduje się tak, jak powinien, i mogę wybrać z listy to, co chcę uruchomić. Zwykle, gdy pojawia się taki bałagan, ponowna instalacja gruba na mbr (za pomocą grub-install ) powinna go naprawić na stałe, więc nie musisz tego robić przy każdym uruchomieniu. Mam jednak trudności z ustaleniem, co zrobić, jeśli naprawienie tego nie jest takie proste (lub podzieliłbym się tym, co powinieneś zrobić).

Tylko jeśli to się nie powiedzie (np. Jeśli prefiks jest poprawny, ale nadal nie można uruchomić systemu), powinieneś skorzystać z Live lub uratować płyty CD, aby obejść problem (najlepiej tego uniknąć)

Właśnie miałem ten problem dzisiaj po nowej instalacji Mint 15.

Instalator utworzył /boot/grub/x86_64-efimoduły, ale nie zwykłe/boot/grub/i386-pc moduły.

Ponowna instalacja Grub z Live CD naprawiła problem.

Zamień / dev / sda i / dev / sda1 na urządzenie rozruchowe i partycję rozruchową i uruchom następujące polecenia z Live CD:

sudo mount /dev/sda1 /mnt
sudo grub-install --boot-directory=/mnt /dev/sda
sudo reboot

Dzięki za twój post. Rozwiązałem prawie identyczny komunikat o błędzie - „nie znaleziono” pliku /grub2/i386-pc/normal.mod „nie znaleziono” po nowej instalacji systemu Linux CentOS 5.11 na starym komputerze Dell Optiplex z systemem Windows Vista, aby utworzyć podwójny system rozruchowy.

To, co skomplikowało moją sytuację, to to, że już próbowałem i nie udało mi się zainstalować nowszej dystrybucji Fedory 20, która używa GRUB2 zamiast GRUB (LEGACY), na domyślnych partycjach FEDORA. Następnie próbowałem zainstalować CentOS bezpośrednio nad tym, zachowując partycję Windows i nadpisując partycje FEDORA.

Podczas instalacji CentOS zostawiłem pierwszą partycję (Windows) samą (hd0,0) i utworzyłem katalog / boot na drugiej partycji (boot) (hd0,1). Następnie postanowiłem nie modyfikować MBR i zamiast tego wybrałem inną opcję (bootloader na innej partycji).

Po tym, co wyglądało na udaną instalację, ponownie uruchomił się na powyższym błędzie.

Podejrzewam, że informacje o rozruchu na pierwszej partycji nadal wskazywały na lokalizację GRUB2. Procesor nie mógł znaleźć normal.mod, być może dlatego, że wcześniej utworzone partycje FEDORA00 zostały usunięte.

Oto moje kroki:

1. Uruchom z instalacyjnej płyty CD Centos 5 w trybie ratunkowym („ratowanie Linuxa”).

2. Zamontuj dysk lokalny: chroot / mnt / sysimage

3. Przełącz do trybu pojedynczego użytkownika: su

4. Zaktualizuj instalację CentOS: aktualizacja yum

5. Użyj edytora emacs, aby dodać „Microsoft Windows Vista” do pliku grub.conf: emacs /boot/grub/grub.conf i ustaw Vista jako domyślny system operacyjny.

   ( UWAGA: Patrz www.cyberciti.biz/faq/grubconf-for-windows-vista-or-xp-dual-boot/ oraz https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html /Installation_Guide/sn-medialess-editing-grub-conf.html .)

6. Próba aktualizacji MBR: grub-install / dev / hda

7. Uruchom ponownie niezidentyfikowany błąd GRUB, w którym procesor zawiesił się po wyświetleniu „GRUB”.

8. Uruchom ponownie z oryginalnego dysku instalacyjnego systemu Windows Vista (lub innego dysku odzyskiwania systemu Windows) i wybierz opcję naprawy dysku. Odbierz komunikat, że MBR został naprawiony.

9. Uruchom ponownie poprawnie w systemie Windows Vista.

Jestem pewien, że istnieją bardziej eleganckie rozwiązania, ale to zadziałało dla mnie. Próbowałem również pobrać pakiet migracji GRUB do GRUB2, jak opisano na stronie http://help.ubuntu.com/community/Grub2/Upgrading , próbując:

$ yum install grub-pc

Ale nie mógł znaleźć paczki. Być może powinienem po prostu spróbować yum install grub.

Dodawanie do flittermice ...

jeśli uruchamiasz komputer z USB i masz folder i386, możesz otworzyć folder i386 na uszkodzonej części jako root, a następnie skopiować działający folder i386 z usb.

Do mojego systemu CentOS 6.7 dostałem się w dwóch etapach. Najpierw zastosowałem się do powyższych wskazówek flittermice, uruchomiłem z live CD, podłączyłem mój / dev / sda2 jako / mnt i po prostu skopiowałem folder i386-pc z / mnt / usr / ... (możesz znaleźć gdzie jest twój by find /|grep i386) do / boot / grub i zrestartowano.

To dało mi grub> zamiast grub ratowanie> ;-).

Następnie skorzystałem z przewodnika tutaj [ https://www.linux.com/learn/tutorials/776643-how-to-rescue-a-non-booting-grub-2-on-linux/], aby znaleźć i uruchomić moja partycja. Było to (hd0,2), ponieważ (hd0,1) zostało zabrane przez swap.

Później doszedłem do wniosku, że uczynienie tego rozruchu „automatycznym” nie było możliwe, prawdopodobnie dlatego, że mój / boot był na ext4 o rozmiarze i-węzła 256, a stary grub1 wymaga 128. Spróbuję wykonać kilka poleceń z [ http: // kb.kristianreese.com/index.php?View=entry&EntryID=113], aby przygotować partycję przed instalacją.

Zainstaluj ponownie Ubuntu. Idź do „zrób coś innego”. Wybierz partycję instalacyjną systemu Windows jako lokalizację, w której powinien zainstalować moduł ładujący.

Jeśli masz istniejącą instalację systemu Windows, musisz zainstalować GRUB na tej samej partycji; w przeciwnym razie problem będzie widoczny w pytaniu.

Dotyczy to 14, 15, 16, 17 Ubuntu wszystkich wersji i prawdopodobnie wcześniejszych wersji. Na pytanie, gdzie zainstalować moduł ładujący, nie twórz i nie zaznaczaj partycji / boot; zamiast tego użyj partycji Windows.

Dziękuję Ci.

Wypróbuj live grub CD: http://ccm.net/faq/2677-super-grub-disk-live-cd Następnie terminal: cp -r / usr / lib / grub / i386-pc / boot / grub był jedyna rzecz Ta metoda działała dla mnie.