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?
Grub has a small core image that is loaded at boot time. The core image dynamically loads modules which provide further functionality. A normal.mod not found error 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 the grub and grub rescue shells you can explore the drives, partitions, and filesystems. You need to:
$prefix and $rootThe 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 rescue> ls
(hd0) (hd0,msdos1) (hd0,msdos2)
grub rescue> ls (hd0)
error: unknown filesystem.
grub rescue> ls (hd0,msdos1)/i386-pc/normal.mod
error: file '/boot/grub/x86_64-efi/normal.mod' not found.
grub rescue> ls (hd0,msdos1)/grub/i386-pc/normal.mod
error: file '/boot/grub/x86_64-efi/normal.mod' not found.
Found it at (hd0,msdos1)
grub> ls (hd0,msdos1)/boot/grub/i386-pc/normal.mod
normal.mod
Why did GRUB not find it?
Check $prefix (the GRUB directory's absolute location), and $root (the default device for paths that do not include a device).
$prefix is set when grub is installed by grub-install, and $root is initially set to the device from $prefix
grub rescue> echo $root
hd0,msdos2
grub rescue> echo $prefix
(hd0,msdos2)/boot/grub
Root and prefix are pointing to the wrong partition (hd0,msdos2), so we must set them to point to (hd0,msdos1), the partition where normal.mod is actually located
grub rescue> set root=(hd0,msdos1)
grub rescue> set prefix=(hd0,msdos1)/boot/grub
Load and run normal module
grub rescue> insmod normal
grub rescue> normal
ls: List all devices and partitions
grub> ls
(hd0) (hd0,msdos5) (hd0,msdos1)
ls Partition
grub rescue> 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 rescue> 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 rescue> ls (hd0,msdos1)/boot/grub
i386-pc/ locale/ fonts/ grubenv grub.cfg
search or search.file commands are not recognised set $prefix correctly and then do insmod search, for ls do insmod ls etc. Run find /boot/grub -name *.mod on a working Linux install to see all of the dynamically loaded Grub modules.
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 --boot-directory=/mnt
Original solution for this was from here: http://ubuntujournal.blogspot.com/2012/11/fix-new-install-of-ubuntu-1210-wont-boot.html
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.
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.
I had the same issue and could not get it resolved using Grub-Rescue. I tired most of the solutions offered here.
I then booted off the Ubuntu live media (DVD or USB) and installed the boot-repair-tool and this resolved it for me
Reinstalling grub from the above answer from MorrisseyJ (https://askubuntu.com/a/286028/795299) helped, but I still had the module not found error. It was looking for the files at /grub.. instead of /boot/grub.. Even after reinstalling grub with several methods, something kept pointing there (grubenv maybe). Finally, I renamed the /boot directory and used the grub-install /dev/sda --boot-directory=/mnt/boot command and it finally changed the $prefix location.
After 4 hours into this mess, I figured out that FS Labels ARE NOT simple names that will appear somewhere.
Seems obvious in hindsight, but well... it wasn't.
The Lubuntu 22.04 installation brought me here and simply reinstalling it WITHOUT those labels solved the issue in a x64, EFI machine.
I really hope you, fellow searcher, figure this out faster than I did :).
In my case the UEFI boot manager was lost from bios setup.
This article from itsFOSS solved the problem:
I simply added an entry pointing at that file shimx64.efi
i. Backup your important files, first.
The second 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.
--Update-- I got a lot of down-votes on this. I just want to say that this error can be caused by more than one antecedent. Even though this has worked for me, it might not work for you so backup your important files before fiddling with things.
The top-rated solution worked for me on some devices, also, but it did not work on one of my devices so I created this answer rather than amending other answers.
