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