Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[MiloMak]

Updated from 2.02+dfsg1-20 to 2.04-1 like the op and get similar to the op https://i.imgur.com/jKYXOHs.png when i downgrade back to 2.02 grub boots without issue. I have debian installed as: /dev/sdc1    /boot/efi /dev/sdc2    /                (/boot is here) it has been working with: # grep 'set root' /boot/grub/grub.cfg set root='hd2,msdos2' i see you say that the problem is most probably caused by a misconfiguration. what should i be checking and how do i fix it? On Fri, 12 Jul 2019 10:16:57 +0100 Colin Watson <cjwat...@debian.org> wrote: > On Fri, Jul 12, 2019 at 02:57:42AM +0200, Sebastian Ramacher wrote: > > since the last update the grub no longer works. It fails very early with > > > > symbol `grub_file_filters` not found > > > > and enters the rescue shell. After downgrading it back to 2.02+dfsg1-20 > > everything works again as expected. > > This means that your GRUB installation is misconfigured: in particular, > it means that the GRUB core image that your firmware is configured to > boot from is not the one that grub-install is writing to on upgrade, > which means that the core image and the loadable modules in /boot/grub/ > are incompatible and you get this failure mode. > > This is not a bug in the new version of GRUB; any upgrade at all that > changed the interface between the core image and modules (which is not a > stable interface) would have exposed this. Rather, it's a bug in the > way your system was installed or possibly in the way it has been > maintained since then, and unfortunately it's prohibitively difficult > for the GRUB packaging to detect this sort of problem; while we can do > our best to predict what the firmware is going to boot from (and it's > usually easier with UEFI), we can't do a perfect job of that. > > Since you're using grub-efi-amd64, here are a few tips for things to > investigate: > > * Is your firmware actually set up to boot your system using UEFI? If > you had grub-efi-amd64 installed (declaring that your system's boot > process is owned by a UEFI boot loader), but your firmware is > actually booting from an old BIOS core image that was once installed > using grub-pc, then that would cause this problem. > > * Do you have multiple EFI System Partitions on different disks? If > so, it's possible that /boot/efi isn't the one your firmware is > actually using. > > * Perhaps your firmware is one of those that requires the boot loader > image to be in the so-called "removable media path" > (/EFI/Boot/bootx64.efi on the EFI System Partition) despite being on > a fixed disk, and in that case perhaps you used grub-install's > --force-extra-removable option or otherwise manually put it there. > If you don't remember, you can try to check for this, although > imprecisely, by seeing whether "strings > /boot/efi/EFI/Boot/bootx64.efi" (or case variations of that) mentions > "GRUB" or "shim". In that case, use "dpkg-reconfigure -plow > grub-efi-amd64" and answer yes to the "Force extra installation to > the EFI removable media path?" question. > > -- > Colin Watson [cjwat...@debian.org] > >