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

17

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?

Gryf
źródło
Druga sugestia (z liveCD i chroot) jest prawdopodobnie warta wypróbowania. Lub wariacja na ten temat: nie jestem użytkownikiem arch, ale zainstalowałem go wcześniej i z tego, co pamiętam, możesz rozważyć tę sugestię w odniesieniu do różnych etapów instalacji arch, z których niektóre wymagają chroota. Jeśli możesz wrócić do poprzedniego kroku, uruchamiając arch CD, a następnie instalując i chrootując w swojej instalacji, powinieneś być w stanie spróbować grub-install. Nie musisz powtarzać żadnego z tych kroków, po prostu użyj ich jako przewodnika, aby uzyskać chrootację z liveCD.
goldilocks
Chociaż nie jestem teraz przy komputerze, wydaje mi się, że próbowałem zainstalować gruba i nie zadziałało.
Griffin
@Griffin Nie działało, ponieważ nie powiodło się w przypadku „grub-install” lub nie rozwiązało problemu?
derobert
@derobert grub-install nie był prawidłowym poleceniem \
Griffin
@gililocks Drugi też nie działa
Griffin

Odpowiedzi:

9

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
flittermice
źródło
Zrobiłem to również, ponieważ tego również brakowało. Niestety to nie naprawiło.
Wolfpack'08,
8

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ąć)

Cestarian
źródło
To może być trochę stare pytanie, ale okazało się, że ktoś musiał odpowiedzieć, jak właściwie korzystać z ratowania gruba zamiast wymachiwać przy użyciu żywych płyt CD i USB do naprawy rzeczy. Nie zawsze mamy pod ręką media na żywo, które mogą nam pomóc, a nawet jeśli to robimy, zwykle lepiej jest pracować w naszym preferowanym środowisku.
Cestarian
Świetne wyjaśnienie! (Szczególnie uwaga na temat „zgadywania źle nic nie zaszkodzi”). Zetknąłem się z tym samym problemem z systemem Windows z podwójnym rozruchem i systemem Ubuntu, po błędnym pomyśle, że usunięcie partycji Windows nie będzie miało wpływu na Ubuntu. W każdym razie ten post naprawdę pomógł zrozumieć, jak naprawić błąd. Ponieważ nie mogłem sobie przypomnieć, która partycja zawierała gruba, po prostu wymieniłem je wszystkie ls, a następnie wypróbowałem je jeden po drugim, aż trafiłem na odpowiednią kombinację :-)
Leigh
@Leigh cieszę się, że pomógł komuś :)
Cestarian
1
Naprawianie czegoś jest zawsze dobre, ale zrozumienie, jak to naprawiłeś, jest jeszcze lepsze :-) Pozdrawiam.
Leigh
Jesteś geniuszem
Ashish Doneriya
5

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
Jamesallman
źródło
1

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.

dkergyl
źródło
0

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.

Jacob David C. Cunningham
źródło
0

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ą.

Pavel Anaschenko
źródło
0

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.

Wolfpack'08
źródło