Home / ubuntu / Questions / 1183951
Accepted
Eugene msc
Asked: 2019-10-27 02:02:08 +0800 CST

grub_file_filters not found after Ubuntu 19.10 upgrade

  • 772

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

grub2 grubrescue 19.04 19.10

9 Answers

  1. 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
# If you used a logical volume, your volume should be named `/dev/mapper/ubuntu--vg-root` and not `/dev/sdxx`

# 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
    • 27

  2. 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

    Note - if you have more than one physical disk, your BIOS may be looking on a different one. You may need to do this for each physical disk.

    • 15

  3. 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.

    • 6
  4. Best Answer

    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

    • 4

  5. 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.

    • 3

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

    • 0

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

  8. 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

  9. 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.

    • 0