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