26

I upgraded Ubuntu from 19.04 to 19.10. The upgrade went without errors but after restart grub throws an error on startup and goes into rescu mode

error: symbol 'grub_file_filters' not found. 
Entering rescue mode... 
grub rescue>

It's a physical machine not a virtualbox, and I have windows and linux in dual boot.

I managed to find what partition is my linux on with ls, but don't really know what to do next.

insmod normal fails with the same error

5
23

In my case, I had an Xubuntu 18.04 VM and after upgrading to 20.04, got the grub error. So I followed what's described here, which is for Kali, but should work for any Linux / grub installation:

  1. Using an Ubuntu / Xubuntu ISO Live enter live mode (I used Ubuntu 20.04 since I had it already downloaded in my computer).

  2. Once inside, I opened a terminal and ran:

# So we can run the next commands as `root`:
sudo su

# To figure which partition had my Xubuntu installation (partition type `Linux`)
# in my case it was `/dev/sda1`, we can use:
fdisk -l

# Let's mount a few things:
mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

chroot /mnt

# Now let's try to fix Grub:
grub-install /dev/sda

If things went well, you should see a message saying something like:

Installation finished. No error reported

  1. Now we can cleanup and reboot:
# To change back chroot:
exit

# And now we can umount all:
umount /mnt/dev/pts
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt

# Now we can reboot:
reboot
4
  • 2
    I ran into this same problem when upgrading from Ubuntu 18.04 LTS to 20.04. Following the instructions in this answer worked perfectly for me using an Ubuntu 20.04 live flash drive.
    – afosbenner
    Oct 11 '20 at 19:55
  • I also upgraded my ThinkPad W520 from 18.04 to 20.04 and fallen into the same problem. following the above (I had ubuntu 18.04 ISO) and it worked. Thank you and to the video Oct 28 '20 at 2:06
  • Nearly gave me a heart attack trying to upgrade Ubuntu 18.04 to 20.04 today, but all it took was a quick grub reinstall and it was up and running. Nov 25 '20 at 19:54
  • I have an efi boot partition, do I need an extra mount in this procedure?
    – Bram
    Oct 4 at 0:26
14

Got the same issue, fixed by booting a 19.10 "rescue" USB key then, in terminal: (where sda is your disk and sda1 is your partition on the disk.)

$ sudo mount /dev/sda1 /mnt
$ sudo grub-install --root-directory=/mnt /dev/sda
4
  • 1
    This one should be the answer. Grub just needs to be re-installed. If you get this error on a default Ubuntu upgrade from 18.04 to 20.04, boot off a live ubuntu USB stick, drop to a shell and type those commands. Fixed it for me in 3 mins.
    – G_Style
    Oct 13 '20 at 20:19
  • I second that this fixed me up during an upgrade from Ubuntu 18 to 20. Feb 20 at 15:28
  • Worked for me after upgrade from Ubuntu 16 to 20. Saved my afternoon. Thanks!
    – Anne Gunn
    Jun 10 at 23:33
  • If I do info grub-install I see no such option of root-directory, but there is a boot-directory option. Are you sure this info is correct?
    – Bram
    Oct 3 at 23:58
6

I couldn't get boot-repair (or boot-repair-disk) working, but managed to fix this by booting from a live Ubuntu 19.10 USB, mounting the old disk, entering chroot, and running grub-install and update-grub.

There is a launchpad bug here, which recommends the chroot fix as described here.

4

I had exactly the same problem about a week ago. I solved it by downloading the boot-repair-disk from sourceforge. You will need to manufacture a bootable USB key or CD if you have a suitable CD drive. There are plenty of guides online about how to do this. I hope you have access to a system where you can do it. You can do it on Windows.

It may be possible to fix it from the grub rescue prompt and then the grub prompt. I tried this first but didn’t have success following a guide I found online.

Good luck

2
  • I only was able to fix this with a live usb stick an boot-reapair. as in WinEunuuchs2Unix's comment. Nothing I did in grub rescue worked
    – Eugene msc
    Oct 26 '19 at 18:14
  • thx. Did the same and it worked. I wrote the iso to a usb with a ubuntu session from a ubuntublive cd
    – mfnx
    Nov 27 '19 at 19:50
3

I too encountered the exact same problem after updating to Ubuntu 19.10. Here is how I (just now) resolved it:

First, you have two problems, not one. Both your installation is screwed up and the Grub Bootloader is messed up. And running only one fix won't fix everything. You need both the "boot-repair-disk" and the latest version of Ubuntu (both on USB boot drives. Don't use a DVD.)

If you try to do (only) a "Repair Install" from the Ubuntu Live disk first, you'll still be greeted by the "grub rescue>" prompt when done. :( So, first you must use the "boot-repair-disk". Tell it to repair your broken boot partition with Ubuntu on it. If you aren't sure of the partition ID, launch "GParted" from the "Start" menu (bottom left.)

Repair that boot partition. This should at least bring Grub back. Try to launch Ubuntu. If it works, you're done. If not, boot the Live "CD" from USB.

Double-click the "Install Ubuntu 19.10" icon on the desktop (don't worry, there will be an option to repair w/o losing your old programs/files.)

I recommend checking the boxes to download all updates during install, including 3rd party.

The Installer should detect your broken partition and give you the option to repair it (the first option.) It may need to disable some 3rd party repositories. Not a big deal, they're easy enough to get back later.

(Note: If you had to login with a password before, don't try to select "login w/o password" now. It won't let you in when you're done.)

Once done, you should have Ubuntu 19.10 installed with all/most of your existing apps still installed (though the toolbar shortcuts will be reset.) I had to reinstall a few 3rd party apps, but their configurations were still there afterwards, so nothing was lost.

0

I had a similar issue on a dual boot with windows. Ran a boot-repair and followed all the steps and everything became normal.

1
  • duplicate of the accepted answer
    – karel
    Feb 19 at 10:19
0

For readers who face this issue while upgrading a cloud-based virtual system, you can mitigate it by re-installing grub and update-grub right after the system upgrade before rebooting. Perhaps even just updating grub before rebooting into the upgraded system could have mitigated it, but I didn't want to risk, and I don't have the time to test that now.

I learnt this the hard way, but I luckily (should I say naturally?) I had a snapshot of the system from right before the attempted system upgrade, so I after reading on the possible causes I restored the snapshot, re-performed the system upgrade, then re-installed grub.

Alas, until this is documented in the cloud providers' documentation somehow or until a workaround is devised that prevents this from happening, there will be no way to guarantee that users who face this are prepared.

I also reported this in a related issue at Launchpad.

0

Worked for me on a fresh install of Ubuntu 20.04 where GRUB apparently did not install correctly.

$ sudo mount /dev/sda1 /mnt
$ sudo grub-install --root-directory=/mnt /dev/sda

as described above in previous post (use the values for your installation in place of /dev/sda1 and /dev/sda)

0

I am copying my solution to here seems that this one is more visible thread.

What DID NOT WORK

  1. I had the same issue and above solution by @rapid3642 DID NOT WORK. The CHROOT case was not the right case for me because I could use F12 and able to log in to linux without issue. I also tried running the above commands as chroot on ubuntu system / partition directly ( without the mounting part as I had ubuntu installed and working )
  2. Rescatux also did not work although it seems to be the utility which was supposed to be a clean gui.

I used a comment from Kristina Kovacek to get the idea of what we need to do.

What did work for me is the boot-repair-disk utility. Funnily enough it did not work in the default mode ( the Recommended Repair section ) but I had to change following

Advanced Options -> Grub location

  1. Change OS to boot by default to the Linux ( yes you can log into windows but you need to keep linux as Master )
  2. Untick Spearate /boot /boot/efi partition
  3. Place grub into <your linux partition such /dev/sda>

I also removed one other option making sure that by default the GRUB looks into windows I dont remember what it was ( even though I executed the procedure just few moments ago

NOTE that there are instructions that you need to follow and commands that you need to execute manually which also involves purging the grub-install from the linux partition ( which in retrospect might have sufficed. )

I believe things can be done by other methods and specially by @mugsy answer seems to be pretty much the same. However my answer doesnt use Gparted and any advanced stuff.

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