error: file '/grub/i386-pc/normal.mod' not found

  • error: file '/grub/i386-pc/normal.mod' not found.
    grub rescue>

    What can I do? I just sit and stare at it.

    I found my old netbook (Dell Inspiron 1010) which I have not used for about four years. I replaced Windows XP with Ubuntu 12.10. I used my bootable USB drive. I installed and rebooted. I got the message that normal.mod is not found.

    What should I do? Type exit, reboot, or quit? Should I re-install?

    THE ANSWER BELOW NEVER WORKS. THIS DOES WORK: re-install your OS, go to "do something else", create your partition tables, then `use your windows partition as your primary boot device`. That last step is essential. DO NOT USE /boot. There might be another solution: try manually changing your boot device during startup; however, I don't think that will work. This is a long-standing problem that has persisted in Ubuntu up-to and including 17.10. Thank you.

    None of these instructions worked for me. In fact, using the various recovery tools made the problem worse. I was able to get grub sort of reinstalled but because I use lvm2, the kernel failed to start. If you are using lvm2 for anything, then when this problem happens, you will have to reinstall the OS. As far as I can tell, there is no recovery from a failed kernel update + grub + lvm2 combination. lvm2 sees very little official support despite being pushed for Ubuntu Server LTS at one point. I'm backing up my data and reinstalling the OS and won't touch lvm2 again. Learned my lesson.

    @CubicleSoft Yes, such a situation is recoverable, see my answer.

    I already switched away from lvm2 and have had zero issues since. None of my infrastructure uses it anymore. The default system rescue solutions (both graphical and CLI) are unaware or only barely aware of LVM and that is sufficient reason for me to not use LVM. Even if I followed your directions to recover the system and they worked, the problem would probably happen again in the future. Reinstalling the OS and ditching LVM was the best and fastest option for me.

    @Wolfpack in my case the problem is that without normal.mod set prevent me to possibly reinstall ubuntu, the lgoin does nt works. What can I do?

    @Wolfpack'08 Please repost your solution as an answer. Posting solutions as comments is circumventing the site principles. You should also mention _which_ “answer below never works“ since there are more of them.

  • Grub has a small core image that is loaded at boot time. The core image dynamically loads modules which provide further functionality. i386-pc/normal.mod not found indicates that grub can not load normal.mod, which is a grub module that provides the normal command. To load normal.mod you need to tell grub where it is. To do this you can use the grub command-line (aka Rescue Console). Grub will start the command-line if there is a problem booting, or you can start it manually by holding the shift key as grub starts (to force show the grub menu), and then pressing the 'c' key.

    Using grub you can explore the drives, partitions, and filesystems. You need to:

    • locate the grub install using ls or search.file
    • set grub variables $prefix and $root
    • load and run the normal module


    The following is just an example. You will need to adapt it to your local drive and partition setup.

    where is normal.mod? look in some likely locations

    grub> search.file /i386-pc/normal.mod
    error: no such device: /i386-pc/normal.mod
    grub> search.file /grub/i386-pc/normal.mod
    error: no such device: /grub/i386-pc/normal.mod
    grub> search.file /boot/grub/i386-pc/normal.mod

    If you get "Unknown command 'search.file'" this means that the search.file command is not available. This is probably because you are at the grub rescue> prompt and not grub> prompt. In this case you can still carry on and use the ls command and your knowledge of your partition layout to find normal.mod.

    found it at (hd0,msdos1)

    grub> ls (hd0,msdos1)/boot/grub/i386-pc/normal.mod

    why did grub not find it?
    check $prefix - absolute location of the grub directory
    (this is set when grub is installed by grub-install)

    grub> echo $prefix

    check $root - default device for paths that do not include a device
    grub initially sets this to the device from $prefix

    grub> echo $root

    root and prefix are pointing to the wrong partition (hd0,msdos2)
    set $root and $prefix to the partition where we found normal.mod (hd0,msdos1)

    grub> set root=(hd0,msdos1)
    grub> set prefix=(hd0,msdos1)/boot/grub

    load and run normal module

    grub> insmod normal
    grub> normal

    Some other commands that may be helpful

    ls list all devices and partitions

    grub> ls
    (hd0) (hd0,msdos5) (hd0,msdos1)

    ls partition

    grub> ls (hd0,msdos1)
            Partition hd0,msdos1: Filesystem type ext* - Last modification time
    2014-05-08 15:56:38 Thursday, UUID c864cbdd-a2ba-43a4-83a3-66e305adb1b6 -
    Partition start at 1024KiB - Total size 6290432Kib

    ls filesystem (note / at end)

    grub> ls (hd0,msdos1)/
    lost+found/ etc/ media/ bin/ boot/ dev/ home/ lib/ lib64/ mnt/ opt/ proc/
    root/ run/ sbin/ srv/ sys/ tmp/ usr/ var/ vmlinuz initrd.img cdrom/

    look inside /boot/grub
    presence of i386-pc directory means this is a BIOS install
    presence of x86_64-efi directory would indicate an EFI install

    grub> ls (hd0,msdos1)/boot/grub
    i386-pc/ locale/ fonts/ grubenv grub.cfg

    +1 After following these steps to boot into my ubuntu installation I ran `sudo grub-install /dev/sdX` to install my grub. I think the LVM install confused my grub somehow.

    I guess if you get "Unknown command 'search-file' like I just did, it is time to give up. My advice to folks is never install Ubuntu without a Windows Recovery DVD. As I just found out, having a recovery partition is not enough once Grub gets messed up. And also, never install Ubuntu on someone else's Windows computer, because if it messes up they will be really pissed.

    @Scooter See this answer for instructions on reinstalling Grub by booting a live CD/USB.

    @bain Thanks for the reply. In my case did a reinstall from the Ubuntu iso disk. Ubuntu figured out that grub was messed up or maybe it just automatically writes over it, but it redid it to where I was back to being able to boot into Windows again.

    The Grub rescue shell doesn't appear to support any of these commands. "Unknown command 'search.file'"

    Yepp. The author did not read the question. `grub rescue` shell != `grub` shell.

    @Cerin @JPT I've updated the answer to cover that. Afaik the only command here not supported by the rescue shell is `search.file`. A lot of people who end up at this question are stuck at the grub shell so perhaps it's worth including. The recovery method here is the same as that recommended in Grub manual troubleshooting - GRUB only offers a rescue shell so it is appropriate to the rescue shell as well.

    I'm in grub-rescue. If I try to ls anything past `(hd0,msdos1)` i get like `file '/boot/' not found.`.... if I just `ls (hd0,msdos1)/` I'm getting something like `(b:? 5??U??/...`

    This is a very useful answer, it helps you boot when the installer misconfigures the boot folder location. However, it is not a permanent fix, as on the next boot GRUB is again misconfigured.

    Also occurs on 17.10 and 16.04 MATE with or without `/boot` as an exclusive partition using ext4 or ext2 on the `/boot` partition. If you move i386-pc to /boot/grub, the problem persists. Returns "unknown filesystem" when the steps in this answer are followed.

    In my particularly case, this happened because the BIOS itself was booting the wrong disk (by default `hd0`). Changing boot order permanently solved it for me.

    This is also of limited use when trying to create repeatable immutable cloud base images with Packer. Most of the answers appear to be about fixing the deployment rather than the code that provides the deployment.

  • Solved this on a machine this afternoon. It seems that one cause of this problem is the installer thinking that you have EFI secure boot, when you don't and therefore loading the incorrect GRUB files.

    What you need to do is install GRUB 2. To do this you need to boot to the live instance, mount your root partition and install.

    From a live instance, find the partition on which your root partition is loaded. GParted will tell you this, or you could use

    sudo fdisk -l

    Go for the partition in which ubuntu is installed.

    Once you have your partition you need to mount it. Assuming the root partition is on /dev/sda5, that'd be:

    sudo mount /dev/sda5 /mnt

    Then install GRUB 2

    sudo grub-install /dev/sda --root-directory=/mnt [use copy and paste for this one as there are some spaces that you need to get right.]

    Assuming this is your problem, then you should just be able to reboot and everything will work fine.

    Original solution for this was from here:

    Didn't work for me. I have the same problem and I'm still looking for a solution.

    *--root-directory* is now *--boot-directory* in grub2

    Another easy fix that worked for me is to copy the grup backup located in /etc/grub.d/backup to /boot/grub. Check the attached readme for appropriate folders and paths.

    In my case the problem was I have 2 hard drives and the bios sequence was looking on the wrong drive first. That drive had an old corrupted grub installation.

    If you cant tell which is the right one from fdisk, this SO can help (it helped me find which device /media/ubuntu/some-name was on)

    @jhexp Thank you!! You just saved me. I am on a train and had no USB with Ubuntu, nor was bain's solution helping, because the normal.mod was nowhere to be found. What I did was `set prefix=(hd0,msdos5)/etc/grub.d/backup/boot_grub` and then `insmod normal` and `normal` and everything booted!

    Your answer worked. I encountered this problem when I formatted my swap partition (because it was not mounting when I booted). Reinstalling the grub solved my problem. Thanks to you, I don't have to install the Manjaro OS again.

  • I didn't find that information on forums, so I want to share some information despite the fact that this question was asked a long time ago:

    If you have a large (e.g. 1TB) partition with Ubuntu installed and you didn't allocate additional one for /boot/, it could be the reason of such errors. When GRUB starts, it uses biosdisk driver for reading normal drivers from the /boot/grub/ directory. Sometimes, this directory could be physically located on the hard drive somewhere after the maximum supported by biosdisk sector. The issue could appear, for example, after system upgrade. Also, I am always face that issue after fresh installation Ubuntu 13.10, but it could differ, as it depends on motherboard/bios.

    You can check that using grub recovery - after setting correct PREFIX and ROOT, try to ls /boot - if you don't see anything, but can see files there when booting from live cd/flash drive - than you have the issue described above.

    You can do different things to make system bootable, but the only way to avoid that issue in future (during dist-upgrades) is to put /boot directory on a separate small partition.

  • Other solutions may not work if you get to the grub-rescue prompt and/or your configuration uses LVM, this one should.

    Boot on a rescue disk (tip : I keep a small distribution on a dedicated partition of my backup USB disk).

    If you use LVM, find the name of your volume group with lvdisplay or another LVM-related commands. Activate it (otherwise you'll get a mount: special drive /dev/volumegroupname/partition does not exist error when trying to mount) :

    vgchange -a y volumegroupname

    Now mount your usual / partition, e.g. on /mnt :

    mount /dev/volumegroupname/partition /mnt

    Mount a few special devices as well (as well as /boot if on a separate partition) :

    mount -t proc none /mnt/proc
    mount -o bind /dev /mnt/dev
    mount -t sysfs /sys /mnt/sys

    Then chroot into your usual distribution :

    chroot /mnt

    Finally, reinstall GRUB2 — commands may vary depending on your distribution, this works on Slackware (if your drive is /dev/sda) :

    grub-install /dev/sda
    grub2-mkconfig -o /boot/grub2/grub.cfg

    Reboot and you should be done.

  • This is tested-working, in case the above solutions are still non-working:

    1. Re-install your OS, go to "do something else", create your partition tables,
    2. Use your windows partition as your primary boot device.

    The second step step is essential.

    DO NOT USE /boot.

    There might be another solution: try manually changing your boot device during startup; however, I don't think that will work, and I have yet to test it.

    This is a long-standing problem that has persisted in Ubuntu up-to and including 17.10.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM