I recently install arch (hopefully successfully) on my machine. When I went to reboot however I had a problem. I got a black screen with text saying

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

I have since googled looking for an answer. I almost found one here on the Ubuntu forums yet then I saw one of the comments saying it was untrue. There is also another answer but I'm not sure if I want to install from the live CD for fear of messing things up.

You would understand my fear if you too spent 7 hours setting this up after constantly running into partitioning, command, tutorial, and system problems. What a joy.

Anyone know of an easy solution to getting grub working?

  • The second suggestion (with the liveCD and chroot) is probably worth trying. Or a variation on it: I'm not an arch user but have installed it before, and from what I remember, you might want to contemplate that suggestion in relation to the various stages of installing arch, some of which involve a chroot. If you can backtrack to a previous step booting the arch CD and then mounting and chrooting into your installation, you should be able to try grub-install. You don't have to repeat any of the steps, just use them as a guide to get chrooted in from a liveCD. – goldilocks Mar 29 '13 at 19:26
  • While I'm not at the computer right now I do believe I tried the grub install and it didn't work.- – Griffin Mar 29 '13 at 19:34
  • @Griffin It didn't work as in "grub-install" failed, or it didn't fix the problem? – derobert Mar 29 '13 at 20:09
  • @derobert grub-install wasn't a valid command\ – Griffin Mar 29 '13 at 20:21
  • @goldilocks Second one isn't working either – Griffin Mar 30 '13 at 0:40

A really annoying thing...

As apparently the directory /boot/grub/i386-pc was simply not in place, I finally solved the problem by copying the whole /usr/lib/grub/i386-pc to /boot/grub. That's all.

cp -r /usr/lib/grub/i386-pc /boot/grub
  • I also did that because it was also missing. Unfortunately, that didn't fix it. – Wolfpack'08 Nov 8 '17 at 1:20
  • Worked for me. Thanks – mausamsion Nov 27 '20 at 12:56

I'm in the middle of a similar issue (incidentally also on arch)

Grub is failing to find this file and run because it is using an incorrect "prefix" in my case.

Here is what you do. You boot into grub rescue mode, then you simply figure out how to make it boot.

First you run set this will list variables, for example mine is


Now, the prefix is the variable where grub looks for the normal.mod file. In my case hd1,msdos3 is the same as /dev/sdb3 (similarly, hd0,msdos1 would be /dev/sda1) what you may want to do to see a list of valid partitions is type in ls

Now, in my case, again, grub was installed on /dev/sdb1 which was mounted as /boot in my arch partition, so the correct prefix would be (hd1,msdos1)/grub

So for me to boot, I need to do this:

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

In your case you will have to either remember or guess which partition you installed grub on. You can guess wrong, it won't do any harm, the insmod command will simply fail and you can try again with another partition.

After this, grub loads as it normally should, and I can pick out of the list what I want to boot. Normally when a mess like this occurs, reinstalling grub to your mbr (using grub-install) should fix it permanently so you don't have to do this every time you boot. I however am having a lot of difficulty finding out what to do if fixing it isn't this easy (or I'd share what you should do).

Only if this fails (e.g. if the prefix is correct but you still can't boot) should you resort to live or rescue cds to work around the problem (it is best to avoid that)

  • This might be a bit of an old question, but I found that someone had to answer how to actually use grub rescue instead of flailing around using live cds and usbs to fix things. We don't always have live media on hand to help us, and even if we do, it's usually better to work from our preferred environment. – Cestarian Feb 26 '16 at 2:05
  • Great explanation! (Especially the note about "guessing wrong won't hurt anything"). I ran into the same problem with a dual boot windows + Ubuntu system, after mistakenly thinking that deleting a windows partition would have no impact on Ubuntu. Anyway, this post really helped in understanding how to fix the error. Since I could not remember which partition contained grub, I just listed them all with ls, then tried them one by one until I hit the right combination :-) – Leigh Jun 22 '16 at 17:59
  • @Leigh glad it helped someone :) – Cestarian Jun 23 '16 at 5:21
  • 1
    Fixing something is always good, but understanding how you fixed it is even better :-) Cheers. – Leigh Jun 23 '16 at 14:53
  • 1
    You are a genius – Ashish Doneriya May 15 '17 at 15:29

I just had this problem today after a fresh install of Mint 15.

The installer created /boot/grub/x86_64-efi modules but not the regular /boot/grub/i386-pc modules.

A re-installation of Grub from the Live CD fixed the issue.

Replace /dev/sda and /dev/sda1 with your boot device and boot partition and run the following commands from the Live CD:

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

Thanks for your post. I solved a nearly identical error message -- "file '/grub2/i386-pc/normal.mod' not found" after a new installation of Linux CentOS 5.11 on an old Dell Optiplex computer with Windows Vista, in order to make a dual-boot system.

What complicated my situation was that I had already tried and failed to install the newer Fedora 20 distro, which uses GRUB2 instead of GRUB (LEGACY), on FEDORA default partitions. Then I tried to install CentOS directly over that, keeping the Windows partition and overwriting the FEDORA partitions.

During the CentOS installation, I left my first (Windows) partition alone (hd0,0) and created the /boot directory on a second (boot) partition (hd0,1). I then chose not to modify the MBR at the time and instead selected the other option (bootloader on another partition).

After what appeared to be successful installation, it rebooted into the error above.

I suspect that the boot information on the first partition kept pointing to the GRUB2 location. The CPU could not find normal.mod, perhaps because the previously created FEDORA00 partitions had been removed.

Here are my steps:

  1. Boot from my Centos 5 installation CD into rescue mode ("linux rescue").

  2. Mount the local drive: chroot /mnt/sysimage

  3. Switch to single-user mode: su

  4. Update the CentOS installation: yum update

  5. Use the emacs editor to add "Microsoft Windows Vista" to the grub.conf file: emacs /boot/grub/grub.conf, and make Vista the default OS.

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

  6. Attempt to update the MBR: grub-install /dev/hda

  7. Reboot to an unidentified GRUB error, in which the CPU hung after displaying "GRUB".

  8. Reboot from the original Windows Vista installation disk (or other Windows recovery disk) and select the option to repair the disk. Receive message that the MBR has been repaired.

  9. Reboot correctly into Windows Vista.

I am sure that more elegant solutions exist, but this worked for me. I also attempted to download the GRUB to GRUB2 migration package, as described at http://help.ubuntu.com/community/Grub2/Upgrading, by trying:

$ yum install grub-pc

But it couldn't find the package. Perhaps I should have just tried yum install grub.


Adding to flittermice...

if you boot from a USB, and have the i386 folder, you can open the i386 folder on the broken partion as root and then copy the working i386 folder from the usb.


I have got into my CentOS 6.7 system in two stages. First, I have followed the advice from flittermice above, booted from the live CD, mounted my /dev/sda2 as /mnt and just copied the i386-pc folder from /mnt/usr/... (you can find where yours is by find /|grep i386 ) to /boot/grub and rebooted.

This gave me grub> instead of grub rescue> ;-).

Then I have followed a guide here [https://www.linux.com/learn/tutorials/776643-how-to-rescue-a-non-booting-grub-2-on-linux/] to find and boot into my partition. It was (hd0,2), because (hd0,1) was taken by the swap.

Later, I have figured out that making this boot "automatic" was not possible, probably because my /boot was on ext4 with inode size 256, and the old grub1 requires 128. I will try to follow some commands from [http://kb.kristianreese.com/index.php?View=entry&EntryID=113] to prepare the partition before the installation.


Reinstall Ubuntu. Go to "do something else". Select your Windows installation partition as the location where it should install the boot loader.

If you have an existing Windows installation, you must install grub to the same partition; otherwise, you will have the problem seen in the question.

This is relevant for 14, 15, 16, 17 Ubuntu all versions and probably earlier versions. When asked where to install the boot loader, do not create and select a /boot partition; instead, use the Windows partition.

Thank you.


Try the live grub cd : http://ccm.net/faq/2677-super-grub-disk-live-cd Then the terminal : cp -r /usr/lib/grub/i386-pc /boot/grub was the only thing This method worked for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.