Ошибка личинки: файл, '/grub/i386-pc/normal.mod' не найденный?

У меня просто была эта проблема сегодня после новой установки Монетного двора 15.

Установщик создается /boot/grub/x86_64-efi модули, но не постоянный клиент /boot/grub/i386-pc модули.

Переустановка Личинки с Живого CD устранила проблему.

Замените/dev/sda и/dev/sda1 с Вашим устройством загрузки и разделом начальной загрузки и выполните следующие команды с Живого CD:

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

Действительно раздражающая вещь...

Поскольку, по-видимому, каталог/boot/grub/i386-pc был просто не на месте, я наконец решил проблему путем копирования целого/usr/lib/grub/i386-pc в/boot/grub.Это все.

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

Спасибо за ваш пост. Я решил практически идентичное сообщение об ошибке -- "файл '/grub2/i386-pc/normal.mod не найден" после новой установки Linux CentOS 5.11 на старый компьютер Dell Optiplex с Windows Vista, чтобы сделать систему с двойной загрузкой.

Сложность моей ситуации заключалась в том, что я уже пытался и не смог установить новый дистрибутив Fedora 20, использующий GRUB2 вместо GRUB (LEGACY), на разделы FEDORA по умолчанию. Затем я попытался установить CentOS непосредственно над ним, сохранив раздел Windows и перезаписав разделы FEDORA.

Во время установки CentOS я оставил первый раздел (Windows) один (hd0,0) и создал каталог /boot на втором (загрузочном) разделе (hd0,1). Затем я решил не изменять MBR в то время, а выбрать другую опцию (загрузчик на другом разделе).

После того, как установка прошла успешно, он перезагрузился в описанную выше ошибку.

Я подозреваю, что загрузочная информация на первом разделе продолжала указывать на расположение GRUB2. ЦП не смог найти нормальный.mod, возможно, из-за того, что были удалены ранее созданные разделы FEDORA00.

Вот мои шаги:

1. Загрузка с установочного CD Centos 5 в режим восстановления ("linux rescue").

2. Монтаж локального диска: chroot /mnt/sysimage

3. Переход в однопользовательский режим: su

4. Обновление установки CentOS: yum update

5. Использование редактора emacs для добавления "Microsoft Windows Vista" в файл grub.conf: emacs /boot/grub/grub.conf, и превращение Vista в операционную систему по умолчанию.

   (ПРИМЕЧАНИЕ: См. www.cyberciti.biz/faq/grubconf-for-windows-vista-or-xp-dual-boot/ и https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/sn-medialess-editing-grub-conf.html.).

6. Попытка обновления MBR: grub-install /dev/hda

7. Перезагрузка на неопознанную ошибку GRUB, в которой центральный процессор зависал после отображения "GRUB".

8. Перезагрузитесь с оригинального установочного диска Windows Vista (или другого диска восстановления Windows) и выберите опцию восстановления диска. Получите сообщение о том, что MBR был восстановлен.

9. Перезагрузитесь корректно в Windows Vista.

Я уверен, что существуют более элегантные решения, но это сработало. Я также попытался загрузить пакет миграции GRUB в GRUB2, как описано в http://help.ubuntu.com/community/Grub2/Upgrading, попробовав:

$ yum install grub-pc

Но он не смог найти пакет. Наверное, стоило просто попробовать yum install grub.

Добавление во flittermice ...

если вы загружаетесь с USB и у вас есть папка i386, вы можете открыть папку i386 на сломанном разделе как root, а затем скопируйте рабочую папку i386 с usb.

Я столкнулся с аналогичной проблемой (кстати, также с Arch).

Grub не может найти этот файл и запустить потому что он использует неправильный «префикс»

Вот что вы делаете. Вы загружаетесь в режим восстановления grub, а затем просто выясняете, как заставить его загрузиться.

Сначала вы запускаете set , в нем будут перечислены переменные, например, моя -

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

. Теперь префикс - это переменная, в которой grub ищет файл normal.mod.В моем случае hd1, msdos3 совпадает с / dev / sdb3 (аналогично, hd0, msdos1 будет / dev / sda1), что вы можете сделать, чтобы увидеть список допустимые разделы: введите ls

. В моем случае, опять же, grub был установлен на / dev / sdb1, который был смонтирован как / boot в моем разделе архива, поэтому правильный префикс будет (hd1 , msdos1) / grub

Итак, чтобы загрузиться, мне нужно сделать следующее:

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

В вашем случае вам придется либо вспомнить, либо угадать, на какой раздел вы установили grub. Вы можете ошибиться, это не повредит, команда insmod просто не сработает, и вы можете повторить попытку с другим разделом.

После этого grub загружается как обычно, и я могу выбрать из списка то, что я хочу загрузить. Обычно, когда возникает подобный беспорядок, переустановка grub на ваш mbr (с использованием grub-install ) должна исправить это навсегда, поэтому вам не нужно делать это каждый раз при загрузке. Однако у меня большие трудности с тем, чтобы понять, что делать, если исправить это не так просто (или я бы поделился тем, что вам следует делать).

Только если это не удается (например, если префикс правильный, но вы по-прежнему не можете загрузиться), вам следует прибегать к живым или аварийным компакт-дискам, чтобы обойти проблему (лучше этого избежать)

Я попал в свою систему CentOS 6.7 в два этапа. Во-первых, я последовал совету flittermice выше, загрузился с live CD, смонтировал свой / dev / sda2 как / mnt и просто скопировал папку i386-pc из / mnt / usr / ... (вы можете найти, где находится ваш по найти / | grep i386 ) в / boot / grub и перезагрузиться.

Это дало мне grub> вместо grub rescue> ;-).

Затем я следовал руководству здесь [ https://www.linux.com/learn/tutorials/776643-how-to-rescue-a-non-booting-grub-2-on-linux/ ] , чтобы найти и загрузиться в мой раздел. Это было (hd0,2), потому что (hd0,1) было занято свопом.

Позже я понял, что сделать эту загрузку «автоматической» было невозможно, вероятно, потому что мой / boot был на ext4 с размером inode 256, а старый grub1 требует 128. Я постараюсь выполнить некоторые команды из [ http://kb.kristianreese.com/index.php?View=entry&EntryID=113] , чтобы подготовить раздел перед установкой.

ПРОСТО ПЕРЕЗАГРУЗИТЬ -УСТАНОВИТЬ LINUX ЧЕРЕЗ LIVE USB, И НАСТРОЙТЕ GRUB HUB ДЛЯ ДИСКА НА ВАШЕМ УСТРОЙСТВЕ.

Я столкнулся с той же проблемой, но после многих проблем и исправлений, поискав решения, я просто решил переустановить, и это сработало, просто наберитесь терпения.

Я только что столкнулся с этой проблемой в Ubuntu 20.04 и устранил ее менее чем за 5 минут, загрузив работающую Ubuntu с USB-накопителя -и запустив инструмент восстановления загрузки -:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair && boot-repair

@см.:https://help.ubuntu.com/community/Boot-Repair