After upgrading to 19.10, boot screen shows: "Error: symbol 'grub_file_filters' not found."

[Alex N.]

After upgrading to 19.10 the boot screen shows the following error:

Error: symbol 'grub_file_filters' not found.
Entering rescue mode...

I could fix it after i booted Ubuntu 19.10 live and used the chroot repair method as described here https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#chroot-Methode (german)

Workaround
----------
From https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1848797/comments/18
"In any case, right now the best thing to do to repair is to boot from a Live image (USB or CD-ROM), and follow the steps in https://help.ubuntu.com/community/Grub2/Installing#via_ChRoot to repair GRUB by hand, or reinstall."

[Steve Langasek (vorlon)]

Thank you for the bug report. Are you sure of the spelling of the symbol name, 'grub_file_filters'? There is no symbol by this name anywhere in the grub source code. Have you previously done anything to the bootloader on your system that would have involved installing an out-of-tree grub module built from source?

[Alex N. (a-nox)]

Yes, i am sure. I don't think i have done anything to the bootloader, how can i check it? I found the following, if this helps:

$ sudo grep -r grub_file_filters /boot/
Binary file /boot/grub/i386-pc/offsetio.mod matches
Binary file /boot/grub/i386-pc/gzio.mod matches
Binary file /boot/grub/i386-pc/verifiers.mod matches
Binary file /boot/grub/i386-pc/lzopio.mod matches
Binary file /boot/grub/i386-pc/xzio.mod matches

[Kristian Köhntopp (kris-launchpad)]

I just upgraded from 19.04 to 19.10 and am also affected by this bug.

Right now trying to get the box back. The error message is indeed 'grub_file_filters not found'. This happens at the rescue prompt with 'insmod normal' as well.

[Kristian Köhntopp (kris-launchpad)]

In live cd, I managed to mount /boot, and nm'ed all /boot/grub/i386-pc/*.mod files

The following files contain "U grub_file_filters":

gzio.mod
lzopio.mod
offsetio.mod
verifiers.mod
xzio.mod

[Joshua Hoffmann (dc7ia)]

I'm also affected. (But I upgraded from 18.04 to 19.04 to 19.10)

dc7ia

[Alex N. (a-nox)]

I should add, I upgraded from 19.04. My system was originally installed
with 13.10 and has been continuously upgraded.

[Anthony Bruno (aussieguy0)]

I was also affected by this problem after upgrading from 19.04 to 19.10.

I fixed it by using boot-repair, and have the log file it produced. I can provide it, if it will provide any assistance.

[Łukasz Jakubek (lukaszjakubek)]

I my case same problem when upgrading from 19.04 to 19.10 on VirtualBox VM.

[Sebastien Bacher (seb128)]

The error looks similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931896 which has quite some details about what the issue could be

[Takis Issaris (panagiotis-e)]

Same problem here while upgrading from 19.04 to 19.10.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Edward G Prentice (egp)]

I gave up trying to fix this, and instead I did a new install of 19.10 from DVD
My system works now, but I wish I had been able to do the upgrade from 19.04 like
I did with my other Linux machine.

[Jacob Lindquist (5-jacob)]

Same problem. Have been trying to fix this all day. Upgraded 19.04 tó 19.10 it failed and enters grub rescue with grub_file_filters not found. Boot-Repair did not help.
/dev/sda1 is my boot (Ext4 512 MB)
/dev/sda2 Partition 2 extended partition 240 GB
/dev/sda5 Partition 5 240 GB LUKS (encrypted)
And a /dev/mapper/luks-xxxxxxx.../ a LVM2 PV

I am lost and have no idea what to do. :(

Jacob

[Andreas Jung (docjuhnk)]

I too had this problem. Same error message in the grub prompt.

I had to burn a live-cd, and boot from it. Reapairing grub from live-system didn't work, it "failed to get canonical path of /cow". So I reinstalled the whole System while keeping all my settings, files, stuff in /home, and so on

that worked quite well and getting things back to normal is done in no time.

I know, this is no solution to the bug, but I think it's necessary to give people a hint how to at least access their systems again.

[Paul Brown (paubrown)]

Did the dist upgrade from 19.04 to 19.10 and have exactly the same issue

error: symbol: 'grub_file_filters' not found
Entering rescue mode

[mlmartin (michael-mlmartin)]

Had same issue.

Kubuntu 19.04 VM running on Virtualbox Version 6.0.14 r133895, upgraded via instructions on https://help.ubuntu.com/community/CosmicUpgrades/Kubuntu as of 28/10/2019

SATA controller with dynamically allocated .vdi file set as storage, non encrypted.

[Mathieu Trudel-Lapierre (cyphermox)]

This does not appear to be a new issue; but it is newly visible due to the changes in 2.04: we've now upgraded to a new major release of GRUB, and the modules are now no longer compatible with previous releases.

In other words, if you're running into this issue, your system was most likely already broken, possibly for a long while, even if it was not immediately obvious -- somehow the files on disk under /boot are no longer in sync with the copy of the bootloader installed to the MBR, or in the ESP if you're in UEFI mode.

Even though I am not sure what the actual cause of this, one possible explanation of this is modification of the system at some point in the past. For example, if /boot isn't mounted, listed in /etc/fstab; or /boot/efi in the case of UEFI. It is possible this is a side-effect of use of boot-repair tools. It's hard to know, but for now the precise cause is unknown and we will do more testing to figure out how this can happen.

In any case, right now the best thing to do to repair is to boot from a Live image (USB or CD-ROM), and follow the steps in https://help.ubuntu.com/community/Grub2/Installing#via_ChRoot to repair GRUB by hand, or reinstall.

There is additional information about this in the Debian bug report as well, here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931896

[Mugsy323 (ambrosia-1)]

I wish to add this exact same issue (same error, same result) just struck me after attempting to upgrade to 19.10.

I have downloaded the "boot repair disk" ISO from Sourceforge as recommended on another Ubuntu forum, but am wondering if I should use it or the Ubu Live/boot disk?

[Augestflex (augestflex)]

This has hit me too. Just now rebooting after upgrading from 19.04 to 19.10. I can't remember what version of Ubuntu I first started upgrading to from this machine but looking at my old live discs it was either Ubuntu 9.10 or 15.04.

[Mathieu Trudel-Lapierre (cyphermox)]

Are the systems getting this set up for dual-booting at all?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Max Barry (max-maxbarry)]

Got stuck on this today after upgrading from 19.04 -> 19.10. I do dual-boot Windows. Also Ubuntu is on a 2-disk mdadm RAID array.

- I couldn't get boot-repair-disk to work: It wouldn't recognize the internet connection. The LXTerminal it comes with was broken too and didn't respond to keyboard input, so I couldn't fix it.

- I couldn't install boot-repair from within a live Ubuntu 19.10 USB: It refused because of an unmet dependency for package boot-sav, even though I'd added the recommended PPA.

- I did fix it by installing mdadm (sudo apt install mdadm) from within the live Ubuntu USB, reassembling the RAID array (mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1), mounting it, mounting all the other crap you need to make chroot work, entering chroot, then running update-grub and grub-install a few times on both disks (grub-install /dev/sda1, grub-install /dev/sdb1).

[Daniel Pontillo (dpontillo44)]

I too had this issue today. My system is relatively simple:
1) I am using LVM
2) I was running 19.04
3) I was using an nvme drive (NOT /dev/sda as it likely expected)
4) To fix it I used the chroot method outlined on the Wiki, running both 'grub-install' and 'grub-update'

System is a brand new, never previously been upgraded 19.04 system with only this one drive and OS installed (no dual-boot). AMD Ryzen hardware 12-core, with a pcie nvme boot drive.

Think that's all I have for info to report... not the end of the world, but scary when you can no longer ssh into your server. :)

[sacharja (c3521333)]

Seems to be related to the virtualbox guest additions kernel moduls. Was able to restore grub via https://help.ubuntu.com/community/Grub2/Installing#via_ChRoot . Afterwards it was not possible to install the general kernel package. Only after I removed the virtualbox guest additions hwe I was able to install the new kernel that came with 19.10.

[sacharja (c3521333)]

Tested several times from a 19.04 snapshot: as soon as proprietary drivers are used (in my case virtualbox-guest-dkms-hwe) the upgrade will fail and leave grub in this crippled state. Also I cannot deinstall those drivers through a package manager before the upgrade.

But it would be nice if someone else can confirm that this is related to proprietary drivers.

[sacharja (c3521333)]

Update: not related to proprietary drivers (cannot delete/update my own 2 previous posts), even with those deinstalled, the upgrade will fail.

Have an old VM 19.04 from May: after updating this system & then upgrading to 19.10, it will reliably destroy grub. Let me know if you need support to debug this, I'm reliably able to reproduce it.

[Steve Langasek (vorlon)]

On Sun, Nov 17, 2019 at 12:26:48PM -0000, sacharja wrote:
> Have an old VM 19.04 from May: after updating this system & then
> upgrading to 19.10, it will reliably destroy grub. Let me know if you
> need support to debug this, I'm reliably able to reproduce it.

What is the output of 'debconf-show grub-pc' on this VM?

[Ronzo (ronzo)]

Before the upgrade debconf-show grup-pc output (on Ubuntu 19.04) is:

debconf-show grub-pc
  grub-pc/install_devices_failed_upgrade: true
  grub2/device_map_regenerated:
  grub2/unsigned_kernels:
  grub-pc/install_devices_empty: false
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/chainload_from_menu.lst: true
  grub-pc/install_devices_failed: false
  grub-pc/hidden_timeout: false
  grub2/kfreebsd_cmdline:
  grub2/linux_cmdline_default: nomodeset elevator=noop
  grub2/force_efi_extra_removable: false
  grub2/unsigned_kernels_title:
  grub2/linux_cmdline:
* grub-pc/install_devices: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part1
  grub-pc/timeout: 3
  grub2/update_nvram: true
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/disk_description:
  grub2/no_efi_extra_removable: false
  grub-pc/kopt_extracted: false
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part1
  grub-pc/partition_description:
  grub-pc/mixed_legacy_and_grub2: true

[Ronzo (ronzo)]

I've also deployed a new VM from a snapshot where I performed the upgrade to 19.10. So I can provide information on the system before and after the upgrade.

[Ronzo (ronzo)]

I was able to fix it by booting my cloud provider's rescue image and do the following:

mount /dev/sdXY /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
grub-install /dev/sdX
update-grub
exit
reboot

(https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd)

[Luigi Calligaris (luigicalligaris)]

I also experienced the issue after upgrading from Kubuntu 19.04 to 19.10. I am also using LVM as other posters here. I solved the issue with the usual boot from live ISO + mount/chroot + grub-install.

[Walt Boring (walter-boring)]

I just hit this problem while trying to do a do-release-upgrade from ubuntu 18.04 to 20.04.

[Asbjørn Nilsen Riseth (anriseth)]

I hit the same problem as Walt Boring, upgrading from 18.04 to 20.04. It was fixed with the usual live ISO + mount/chroot + grub-install.

[bje (bje)]

Also hit with this problem upgrading from Kubuntu 18.04 to 20.04. I think this really should be a higher severity bug. LTS releases should not be encountering problems like this.

[Steve Langasek (vorlon)]

Marking this bug as higher severity doesn't address the fundamental problem that users encountering this issue have an Ubuntu install which does not know where their boot disk is. Certainly, at install time Ubuntu knew, but something has changed afterwards with the system which causes grub on upgrade to install to the wrong place - leaving the actual boot disk with an old, incompatible grub installed.

As part of the recent grub security update, we have identified several improvements that will ensure grub always successfully installs to *a* disk. But it is not possible to ensure that this is the *correct* disk.

[Ahmad Gharbeia أحمد غربية (gharbeia)]

I faced this issue while upgrading a cloud-based system from 18.04 to 20.04.

Naturally I had created a snapshot of the system before attempting the upgrade it, so when the upgraded system failed to boot, and after having read much of what may have caused it here and elsewhere, I restored the snapshot, re-performed the upgrade, and before rebooting, I re-installed grub and issued an update-grub command.

I'm blind guessing that in my case it had to do with the mapping of the virtual system volume between the guest system and its host/hypervisor. Somewhere in the upgrade grub misses where it should install/update itself.

[Trent Telfer (unnaturalhigh)]

I also experienced this bug when upgrading my Azure VM from 18.04 to 20.04.

Attempting to correct the issue using the following suggested fix:
https://askubuntu.com/a/1188828

Is there any update to if this bug will be fixed?

[Steve Langasek (vorlon)]

A number of upgrade issues were addressed in grub2 2.04-1ubuntu26.4 in 20.04, which was released back in September. I am going to mark this as a duplicate of bug #1891680.

However, where the grub debconf state on a system is /wrong/, it is not possible to guard against this failure on reboot because the running system cannot know which disk, which is not listed in the debconf state, has the out-of-date first-stage bootloader.

If you are running an official Ubuntu image in Azure, it should definitely be in a state that the debconf values are NOT wrong. Please open a separate bug report for this and drop a reference to that bug here.

[Telman Asadov (loviji)]

Due to the end of life (EOL) of Bionic 18.04 (https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices), the issue with "Error: symbol 'grub_file_filters' not found." has become relevant in recent days.

In my experience, when upgrading an Azure VM from Bionic 18.04 to 20.04, the upgrade may fail due to the boot mode (UEFI mode or legacy BIOS mode), which is a crucial factor.

If your previous VM was in Generation 1 and you upgrade to 20.04 LTS, it will switch to UEFI boot mode. As documented in Microsoft's troubleshooting guide (https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/chroot-environment-linux), it's important to create a Rescue VM in the same generation and perform rescue operations to switch back to Legacy BIOS mode (see the 3rd point in the guide).

It's worth noting that Generation 1 Ubuntu 20.04 comes with legacy mode, whereas Generation 2 Ubuntu 20.04 comes with UEFI mode. Therefore, if your previous machine was in Generation 1, you should create a Rescue Linux VM in Generation 1 and perform the operation as described by @Ronzo in comment #31.

In summary, to resolve the "Error: symbol 'grub_file_filters' not found." issue when upgrading from Bionic 18.04 to 20.04 on an Azure VM, it's important to consider the boot mode, create a Rescue VM in the same generation, and switch back to Legacy BIOS mode if necessary.