20

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?

Improve this question
10
  • 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, 2013 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, 2013 at 19:34
  • @Griffin It didn't work as in "grub-install" failed, or it didn't fix the problem?
    – derobert
    Mar 29, 2013 at 20:09
  • @derobert grub-install wasn't a valid command\
    – Griffin
    Mar 29, 2013 at 20:21
  • @goldilocks Second one isn't working either
    – Griffin
    Mar 30, 2013 at 0:40

7 Answers 7

Reset to default
11

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
Improve this answer
4
  • I also did that because it was also missing. Unfortunately, that didn't fix it.
    – Wolfpack'08
    Nov 8, 2017 at 1:20
  • Worked for me. Thanks
    – mausamsion
    Nov 27, 2020 at 12:56
  • unknown command "cp"
    – Muhammad Awais
    Sep 24, 2021 at 12:30
  • cp is not available in the grub rescue shell.
    – EchoLynx
    Oct 6, 2021 at 22:20
9

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

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

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

Improve this answer
9
  • 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, 2016 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, 2016 at 17:59
  • @Leigh glad it helped someone :)
    – Cestarian
    Jun 23, 2016 at 5:21
  • 1
    Fixing something is always good, but understanding how you fixed it is even better :-) Cheers.
    – Leigh
    Jun 23, 2016 at 14:53
  • 1
    You are a genius
    – Ashish Doneriya
    May 15, 2017 at 15:29
6

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
Improve this answer
0
1

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.

Improve this answer
1

I just ran into this problem on Ubuntu 20.04 and fixed it under 5 minutes by booting a live Ubuntu from an USB-stick and then running the boot-repair tool:

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

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

Improve this answer
2
  • Hi AdminBee, i have no connection to it/them. I just woke up yesterday and was confronted with the "normal.mod not found"-problem after leaving my computer on over night so it could install doom 2016 in a win10 partition. I was a bit suprised to see my pc off. Nevermind. I would have tried the tips above, but this is a old pc with messy leftover partitions and a ubuntu/win7/win10 triple boot and i just wasn't in the mood to think through it by myself. And then i remembered using boot-repair years ago. It guides you through the process and helps you find help if it doesn't work out.
    – johnbot81
    Aug 28, 2021 at 13:12
  • Ok, thank you for the clarification. +1
    – AdminBee
    Aug 30, 2021 at 7:47
0

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.

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .