Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On Wed, Aug 07, 2019 at 11:19:55AM +0200, J. Pietschmann wrote: > The problem appears to be that grub 2.04 uses only devices by disk-id > and didn't install on /dev/sda even though grub 2.02 did. No, that's incorrect. GRUB 2.02 behaved just the same way; you just didn't notice the problem because you happened to have a GRUB core image installed on /dev/sda that was compatible with the GRUB modules that you had installed at the time. Things were already broken but you just didn't know it yet. I've said this in this bug already, but I'll keep repeating it: this is *not* a behaviour change in GRUB 2.04. > Fortunately > dpkg-reconfigure grub-pc > fixes the calamity. > What's the preferred way to reinstall grub on a new disk with 2.04? > Preferrably non-interactive/scriptable. "dpkg-reconfigure grub-pc" is preferred. Doing this noninteractively is possible but fiddly: you'd need to figure out the by-id paths for your disks and then do something like this (obviously substituting the correct by-id paths rather than the example ones I've used): echo 'grub-pc grub-pc/install_devices multiselect /dev/disk/by-id/ata-foo /dev/disk/by-id/ata-bar' | sudo debconf-set-selections sudo dpkg-reconfigure --unseen-only grub-pc (I would not disagree that this should be easier; but this has been the case for a long time, and isn't new in 2.04.) -- Colin Watson [cjwat...@debian.org]
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Hi, I have a similar problem with plain grub-pc (no EFI) I use the first two HDD as an MDM array and installed grub on both /dev/sda and /dev/sdb. A few weeks ago the first HDD failed and was replaced, and I used update-grub grub-install /dev/sda afterwards and could reboot the computer without problems. The next reboot after the upgrade to grub 2.04 failed with symbol `grub_file_filters` not found The grub update didn't show anything interesting on the console or dpgk.log The problem appears to be that grub 2.04 uses only devices by disk-id and didn't install on /dev/sda even though grub 2.02 did. Fortunately dpkg-reconfigure grub-pc fixes the calamity. What's the preferred way to reinstall grub on a new disk with 2.04? Preferrably non-interactive/scriptable. Cheers
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Am Dienstag, 30. Juli 2019, 01:21:43 CEST schrieb Jiri Palecek: > On 29. 07. 19 22:12, Max Hofer wrote: > >> I was also hit by this bug after upgrading yesterday (it has been few > >> weeks since I updated the machine). Just like others, I also had to > >> downgrade the following packages to 2.02 to get it working. > >> > >> 1. grub-common > >> 2. grub2-common > >> 3. grub-efi-amd64-bin > >> 4. grub-efi-amd64 > >> 5. grub-pc-bin > > > > I hit the same problem today. Could you please provide the information, > > how you downgraded the packages on a non bootable system? > > You gotta find something that boots. Either installation pendrive or CD, > or live CD or another disc. Then mount your regular disk as in > somedirectory, mount /proc, /sys, /dev in somedirectory, chroot into > somedirectory and then it is a simple matter for apt. (You may have to > edit sources.list) > > I went through it with my qemu images. > > Regards > > Jiri Palecek Thx for pointing me in the right direction, I was able to fix my problem. It seems my system broke because the install_devices was configured to the partition and not the device. $ lsblk --output NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,PTTYPE,MODEL NAME TYPE SIZE FSTYPE MOUNTPOINT PTTYPE MODEL sdadisk 232.9G dosSamsung_SSD_840_EVO_250GB ├─sda1 part 333M ext4 / dos ├─sda2 part 1K dos ├─sda5 part 8.4G btrfs /usr dos ├─sda6 part 2.8G btrfs /var dos ├─sda7 part 27.7G swap [SWAP] dos ├─sda8 part 380M btrfs /tmp dos └─sda9 part 193.4G btrfs /home dos # Configuration which broke my system with the upgrade from 2.02 to 2.04 $ sudo debconf-show grub-pc|grep install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata- Samsung_SSD_840_EVO_250GB_S1DBNSADC65873B-part1 # Configuration which worked when I upgraded from 2.02 to 2.04 $ sudo debconf-show grub-pc|grep install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata- Samsung_SSD_840_EVO_250GB_S1DBNSADC65873B I vaguely remember that one of the grub upgrades (a long time ago) asked me if I would like to change the installation location but as far as I remember I never changed it. Regards Max
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On 29. 07. 19 22:12, Max Hofer wrote: I was also hit by this bug after upgrading yesterday (it has been few weeks since I updated the machine). Just like others, I also had to downgrade the following packages to 2.02 to get it working. 1. grub-common 2. grub2-common 3. grub-efi-amd64-bin 4. grub-efi-amd64 5. grub-pc-bin I hit the same problem today. Could you please provide the information, how you downgraded the packages on a non bootable system? You gotta find something that boots. Either installation pendrive or CD, or live CD or another disc. Then mount your regular disk as in somedirectory, mount /proc, /sys, /dev in somedirectory, chroot into somedirectory and then it is a simple matter for apt. (You may have to edit sources.list) I went through it with my qemu images. Regards Jiri Palecek
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
> I was also hit by this bug after upgrading yesterday (it has been few > weeks since I updated the machine). Just like others, I also had to > downgrade the following packages to 2.02 to get it working. > > 1. grub-common > 2. grub2-common > 3. grub-efi-amd64-bin > 4. grub-efi-amd64 > 5. grub-pc-bin I hit the same problem today. Could you please provide the information, how you downgraded the packages on a non bootable system? Regards Max
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Hi, I was also hit by this bug after upgrading yesterday (it has been few weeks since I updated the machine). Just like others, I also had to downgrade the following packages to 2.02 to get it working. 1. grub-common 2. grub2-common 3. grub-efi-amd64-bin 4. grub-efi-amd64 5. grub-pc-bin > 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. AFAIK, my installation of Debian was pretty straightforward and I haven't tinkered with grub after installation at all. If anything caused GRUB misconfiguration, it is probably Debian Installer. > 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 Provided that multiple people are facing the same problem, maybe a bit more investigation would be helpful to know more about why this suddenly popped up, what is common with all these users' configuration, and whether it is a legit issue, etc.? Regards Balu
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Package: grub-pc Followup-For: Bug #931896 I ran into this bug, too. The values of all set variables (prefix, root) seemed to be sane and "ls $prefix/i386-pc" returned a list of *.mod files as expected. However, when I tried to load the "normal" module, the error was risen again: > grub rescue> insmod normal > error: symbol 'grub_file_filters' not found. Hence, I do not think that this is caused by a misconfiguration of some path variable. Downgrading to 2.02+dfsg1-20 resvoled the issue for me, too. apt log snippet: > Preparing to unpack .../19-grub-pc_2.04-1_amd64.deb ... > Unpacking grub-pc (2.04-1) over (2.02+dfsg1-20) ... > Preparing to unpack .../20-grub2-common_2.04-1_amd64.deb ... > Unpacking grub2-common (2.04-1) over (2.02+dfsg1-20) ... > Preparing to unpack .../21-grub-pc-bin_2.04-1_amd64.deb ... > Unpacking grub-pc-bin (2.04-1) over (2.02+dfsg1-20) ... > Preparing to unpack .../22-grub-common_2.04-1_amd64.deb ... > Unpacking grub-common (2.04-1) over (2.02+dfsg1-20) ... > ... > Setting up grub-common (2.04-1) ... > Installing new version of config file /etc/grub.d/00_header ... > Installing new version of config file /etc/grub.d/10_linux ... > Installing new version of config file /etc/grub.d/20_linux_xen ... > ... > Setting up grub2-common (2.04-1) ... > Setting up grub-pc-bin (2.04-1) ... > Setting up grub-pc (2.04-1) ... > Installing for i386-pc platform. > grub-install: warning: File system `ext2' doesn't support embedding. > grub-install: warning: Embedding is not possible. GRUB can only be > installed in this setup by using blocklists. However, blocklists are > UNRELIABLE and their use is discouraged.. > Installation finished. No error reported. > Generating grub configuration file ... > Found background image: .background_cache.png > Found linux image: /boot/vmlinuz-4.19.0-5-amd64 > Found initrd image: /boot/initrd.img-4.19.0-5-amd64 > Found linux image: /boot/vmlinuz-4.19.0-4-amd64 > Found initrd image: /boot/initrd.img-4.19.0-4-amd64 > done
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On Tue, Jul 16, 2019 at 11:08:25PM +0200, MiloMak wrote: >Updated from 2.02+dfsg1-20 to 2.04-1 like the op and get similar to the op > >[1]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' To save time, I'd just like to point out that whatever "set root" says in /boot/grub/grub.cfg is basically irrelevant here. That describes the expected location of GRUB's modules, but it says nothing about where grub-install is installing GRUB's core image nor about where the firmware is loading GRUB from, and what matters here is that those last two things need to match. (It's also not interesting whether "set root" in your grub.cfg matches the value of the "root" variable that you see at run-time. The "set root" command is just a fallback, and what usually takes effect instead is the following "search" command which causes GRUB to try to find a file system by UUID or similar. On systems with multiple disks, it's unsurprising for this to result in something different from the guessed value.) >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? I think the only thing I can say to you is to repeat the advice I gave in the message that you were replying to just now (that is, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931896#10). You should at least start by going through each one of those questions and answering them. Since you appear to have multiple disks, it seems quite likely that the firmware might be booting from an EFI System Partition that isn't the same as the one you have mounted on /boot/efi, and if so then that's something you need to correct. -- Colin Watson [cjwat...@debian.org]
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
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 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] > >
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On maandag 15 juli 2019 11:22:55 CEST Colin Watson wrote: > output of "sudo debconf-show grub-pc | grep install_devices:". Ohhh, that is an interesting command :) > 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. Did that and selected my NVMe drive and set that also up as boot device in my BIOS (i.e. like it was before), and now it did work. Now that it looks like I (finally) get it, I may play around with it a bit more to get a better understanding of debconf. Which in turn may increase my understanding (and thereby use of) preseeding :) Thanks for your responses and info. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
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 [cjwat...@debian.org]
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
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? $ lsblk --output NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,PTTYPE,MODEL NAMETYPE SIZE FSTYPE MOUNTPOINT PTTYPE MODEL sda disk 279.5G dosWDC_WD3000HLFS-01G6U0 ├─sda2 part20G ntfsdos ├─sda4 part 1K dos ├─sda5 part 8G swap [SWAP] dos └─sda6 part 249.8G ext4 /home/diederik/media dos sdb disk 232.9G dos Samsung_SSD_750_EVO_250GB └─sdb3 part 232.9G ext4dos sdc disk 931.5G gpt Samsung_SSD_860_EVO_1TB └─sdc1 part 400G ext4gpt nvme0n1 disk 953.9G gptSamsung SSD 960 PRO 1TB ├─nvme0n1p1 part 3M gpt ├─nvme0n1p2 part 4G ext4 /bootgpt ├─nvme0n1p3 part30G ext4 /gpt ├─nvme0n1p4 part 108.6G ext4gpt └─nvme0n1p5 part 811.3G ext4 /homegpt (I might do a complete fresh install in which case my worry would be moot) > > Will 'dpkg-reconfigure grub' update the debconf database and thereby fix > > that problem? > > grub-pc not grub, but yes, that updates the debconf database. Thanks. > NEWS file entries document issues that relate to upgrading to specific > newer versions. However, as I noted in my original closing message, > this isn't triggered by upgrading to any specific version, but rather > simply by upgrading or downgrading to *any* version ... I just checked and saw that even old-old-stable has version 2.02X, so I might have actually ran into this issue before, but just not remember it or I did not have this issue to begin with. I see/agree with your point and hopefully you won't have to deal with lots of bug reports like this. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On Sun, Jul 14, 2019 at 11:56:39PM +0200, Diederik de Haas wrote: > On zaterdag 13 juli 2019 09:05:44 CEST Sven Joachim wrote: > > What I finally figured out after getting my system to boot again, is > > that grub was still configured to install its core image to /dev/sda, > > the old hard disk. This configuration is apparently only stored in the > > debconf database and nowhere else. > > 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. > Will 'dpkg-reconfigure grub' update the debconf database and thereby fix that > problem? grub-pc not grub, but yes, that updates the debconf database. (This is not the same problem that the original reporter of this bug had; they were using UEFI, not BIOS, which is generally less susceptible to this class of problem although apparently they still managed to run into it. In your case the bug is in whatever documentation advised you to simply run grub-install when switching over to a new disk rather than reconfiguring the system to make this persistent.) > Storing that value in f.e. /etc/default/grub seems like a much more logical > place (to me). In the abstract I can see that point, but I'm afraid that specific location isn't possible since that file is used by a different layer of the code. At some point it would probably be a good idea to put the configuration somewhere in /etc instead, although I'm sure people would still miss it. > I understand that this bug was closed as it was in my case indeed a > misconfiguration. Due to the closing of the bug, apt-listbugs didn't inform > me > of a potential issue and it also didn't turn up when I started reportbug > myself to report the issue. I happened to see this bug by accident. > Having the NEWS file inform me and others of this potential issue would've > been > nice and probably prevents several similar bugs from being reported. NEWS file entries document issues that relate to upgrading to specific newer versions. However, as I noted in my original closing message, this isn't triggered by upgrading to any specific version, but rather simply by upgrading or downgrading to *any* version with a different interface between core image and modules. While this happens to have been somewhat stable for a while, it could in principle change as frequently as every single package upload, so the NEWS file isn't a suitable place to discuss it. -- Colin Watson [cjwat...@debian.org]
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Thanks for your reply, it was very helpful :) On zaterdag 13 juli 2019 09:05:44 CEST Sven Joachim wrote: > Most likely you had grub configured to install to the wrong disk, this > is what happened to me. When I installed an SSD into my old PC back in > December 2016, I copied all files from the already present hard drive, > ran "grub-install /dev/sdb" and told the BIOS to boot from the SSD > (which is /dev/sdb). Everything was working fine until I upgraded > grub-pc to version 2.04. That sounds familiar. $ grep 'set root' /boot/grub/grub.cfg set root='hd0,msdos2' And that indeed points to my WinXP partition. Which makes sense as this system was setup as dual boot between WinXP (installed first) and Debian. But I had configured in my BIOS (in an updated system with new MB/CPU/RAM/etc) to use my NVMe drive as first boot option. And that turned out to be the misconfiguration Colin talked about. Setting it to the drive that hosts my WinXP drive, made it work again. > What I finally figured out after getting my system to boot again, is > that grub was still configured to install its core image to /dev/sda, > the old hard disk. This configuration is apparently only stored in the > debconf database and nowhere else. 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. Will 'dpkg-reconfigure grub' update the debconf database and thereby fix that problem? Storing that value in f.e. /etc/default/grub seems like a much more logical place (to me). I understand that this bug was closed as it was in my case indeed a misconfiguration. Due to the closing of the bug, apt-listbugs didn't inform me of a potential issue and it also didn't turn up when I started reportbug myself to report the issue. I happened to see this bug by accident. Having the NEWS file inform me and others of this potential issue would've been nice and probably prevents several similar bugs from being reported. Thanks again for your help, Diederik signature.asc Description: This is a digitally signed message part.
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
On 2019-07-12 23:24 +0200, Diederik de Haas wrote: > Package: grub-efi-amd64 > Followup-For: Bug #931896 > > I don't have grub-efi-amd64 installed, but I ran into the same problem. > The only enabled lines in /etc/default/grub are these: > GRUB_DEFAULT=0 > GRUB_TIMEOUT=5 > GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` > GRUB_CMDLINE_LINUX_DEFAULT="quiet" > GRUB_CMDLINE_LINUX="" > > Which, afaik, is the default. > The versions reported are what's currently installed as with 2.04 my > system doesn't boot. > > I'm not sure/don't understand what Colin meant with 'firmware'. My guess > would be my BIOS, but I haven't changed that recently. It is the system's firmware, called UEFI on modern systems or BIOS on older ones, where you would install grub-pc rather than grub-efi-amd64. > But up until version 2.04 grub2 has worked perfectly well and I don't > recall me having configured anything manually, so I wouldn't know why > it would be misconfigured. Most likely you had grub configured to install to the wrong disk, this is what happened to me. When I installed an SSD into my old PC back in December 2016, I copied all files from the already present hard drive, ran "grub-install /dev/sdb" and told the BIOS to boot from the SSD (which is /dev/sdb). Everything was working fine until I upgraded grub-pc to version 2.04. What I finally figured out after getting my system to boot again, is that grub was still configured to install its core image to /dev/sda, the old hard disk. This configuration is apparently only stored in the debconf database and nowhere else. > I can send my grub.cfg in a separate email if that would help. > (How can I do a followup with bugreport so that the full output is > reported as you'd get with an initial filing of a bug?) You can run "reportbug --template grub-pc" and paste the output to your preferred mailer. Cheers, Sven
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Package: grub-efi-amd64 Followup-For: Bug #931896 I don't have grub-efi-amd64 installed, but I ran into the same problem. The only enabled lines in /etc/default/grub are these: GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet" GRUB_CMDLINE_LINUX="" Which, afaik, is the default. The versions reported are what's currently installed as with 2.04 my system doesn't boot. I'm not sure/don't understand what Colin meant with 'firmware'. My guess would be my BIOS, but I haven't changed that recently. But up until version 2.04 grub2 has worked perfectly well and I don't recall me having configured anything manually, so I wouldn't know why it would be misconfigured. Downgrading to version 2.02+dfsg1-20 makes it work again I can send my grub.cfg in a separate email if that would help. (How can I do a followup with bugreport so that the full output is reported as you'd get with an initial filing of a bug?) I get no errors during the upgrade to 2.04: root@host:~# aptitude unhold grub-pc root@host:~# aptitude safe-upgrade Resolving dependencies... The following packages will be upgraded: grub-common grub-pc grub-pc-bin grub2-common 4 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 0 B/4,283 kB of archives. After unpacking 1,353 kB will be used. Do you want to continue? [Y/n/?] Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done Preconfiguring packages ... (Reading database ... 514663 files and directories currently installed.) Preparing to unpack .../grub2-common_2.04-1_amd64.deb ... Unpacking grub2-common (2.04-1) over (2.02+dfsg1-20) ... Preparing to unpack .../grub-pc_2.04-1_amd64.deb ... Unpacking grub-pc (2.04-1) over (2.02+dfsg1-20) ... Preparing to unpack .../grub-pc-bin_2.04-1_amd64.deb ... Unpacking grub-pc-bin (2.04-1) over (2.02+dfsg1-20) ... Preparing to unpack .../grub-common_2.04-1_amd64.deb ... Unpacking grub-common (2.04-1) over (2.02+dfsg1-20) ... Setting up grub-common (2.04-1) ... Installing new version of config file /etc/grub.d/00_header ... Installing new version of config file /etc/grub.d/10_linux ... Installing new version of config file /etc/grub.d/20_linux_xen ... Setting up grub2-common (2.04-1) ... Setting up grub-pc-bin (2.04-1) ... Setting up grub-pc (2.04-1) ... Installing for i386-pc platform. Installation finished. No error reported. Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-4.19.0-5-amd64 Found initrd image: /boot/initrd.img-4.19.0-5-amd64 Found linux image: /boot/vmlinuz-4.16.0-2-amd64 Found initrd image: /boot/initrd.img-4.16.0-2-amd64 Found linux image: /boot/vmlinuz-4.13.0-1-amd64 Found initrd image: /boot/initrd.img-4.13.0-1-amd64 Found linux image: /boot/vmlinuz-4.9.0-3-amd64 Found initrd image: /boot/initrd.img-4.9.0-3-amd64 Found memtest86+ image: /memtest86+.bin Found memtest86+ multiboot image: /memtest86+_multiboot.bin Found Microsoft Windows XP Professional on /dev/sda2 done Processing triggers for man-db (2.8.5-2) ... Processing triggers for install-info (6.6.0.dfsg.1-2) ... WinXP doesn't actually boot iirc (been a LONG while since I tried) and the remaining non-upgraded packages are due to #928631. If you want/need more info, let me know. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grub-efi-amd64 depends on: ii debconf [debconf-2.0] 1.5.72 ii grub-common2.02+dfsg1-20 pn grub-efi-amd64-bin ii grub2-common 2.02+dfsg1-20 ii ucf3.0038+nmu1 grub-efi-amd64 recommends no packages. grub-efi-amd64 suggests no packages.
Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found
Package: grub-efi-amd64
Version: 2.04-1
Severity: grave
Hi,
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.
Cheers
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/neptun-vg/root / ext4 rw,relatime 0 0
/dev/sda2 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
else
search --no-floppy --fs-uuid --set=root d7aaa367-61ca-446f-b815-c2e79b8e4dfa
fi
font="/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
else
search --no-floppy --fs-uuid --set=root d7aaa367-61ca-446f-b815-c2e79b8e4dfa
fi
insmod png
if background_image /grub/.background_cache.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-74ba39e5-850a-42b8-93da-84fc7730af1e' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
else
search --no-floppy --fs-uuid --set=root
d7aaa367-61ca-446f-b815-c2e79b8e4dfa
fi
echo'Loading Linux 4.19.0-5-amd64 ...'
linux /vmlinuz-4.19.0-5-amd64 root=/dev/mapper/neptun--vg-root ro
intel_iommu=off quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-4.19.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-74ba39e5-850a-42b8-93da-84fc7730af1e' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-5-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-4.19.0-5-amd64-advanced-74ba39e5-850a-42b8-93da-84fc7730af1e' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio;
fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint
