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

Colin Watson cjwatson at debian.org
Mon Jul 15 10:22:55 BST 2019


On Mon, Jul 15, 2019 at 01:51:59AM +0200, Diederik de Haas wrote:
> On maandag 15 juli 2019 00:33:31 CEST Colin Watson wrote:
> > > In the not too distant future, I'll remove that old drive (with WinXP on
> > > it) from my system and my guess is that I then will have a problem.
> > 
> > That shouldn't be the case: we store the installation device using a
> > /dev/disk/by-id/ path, which isn't affected by removing other disks.
> 
> It's not just any disk, it's the disk that grub-install is writing to on 
> upgrade (iiutc), i.e. 'hd0,msdos2'. It should then boot (directly) from 
> my NVMe drive, with has a gpt partition table. Pointing my BIOS to 
> boot from that NVMe drive caused this problem for me and changing 
> that to the drive-to-be-removed, fixed it.
> Would that still not matter?

Yep, I understand your situation.  The Debian GRUB packaging remembers
which device it should run grub-install on using a /dev/disk/by-id/
path, which you can see in the output of "sudo debconf-show grub-pc |
grep install_devices:".  This is a stable reference to the device which
is not affected by adding or removing other disks (unlike e.g. /dev/sd*
device names, which can be affected by such things).

You certainly do need to run "dpkg-reconfigure grub-pc" to match what
your BIOS is configured to boot from.  However, once you do that,
removing the old drive shouldn't be a problem.

> (I might do a complete fresh install in which case my worry would be moot)

Of course you can, but it shouldn't be necessary for this.

-- 
Colin Watson                                       [cjwatson at debian.org]



More information about the Pkg-grub-devel mailing list