the new version of grub (2.04) introduced in the lastest version of Tumbleweed is (obviously) not compatible with old version (2.02) due to introducing new symbols (e.g.: the ‘grub_file_filters’ mentionned in the error message)
the new version of grub refuses to install the BIOS bootloader (i386-pc) on ‘unsafe’ partition that require blocklist (e.g.: ext2/3/4).
So if you update 2.02 -> 2.04 on a machine that is still using BIOS for its firmware, and have your “/boot” partition on the list of places where the grub bootloader needs to be installed,
the “update-bootloader” step (which is supposed to call “grub2-install” for every location) fails and you’re left with an unbootable system (all the copies of the bootloader are still the old 2.02 version, the grub modules are the new 2.04 and incompatible) which can’t even be recovered from the grub recovery.
You only get error message about “symbol ‘grub_file_filters’ no found” no matter what you do.
Solution:
boot into a recovery system
run
sudo grub2-install --target=i386-pc /dev/sda'
to manually install grub2’s i386-pc bootloader version 2.04 onto your partition table.
the system is now bootable, reboot
run YaST and reconfigure the bootloader to ONLY INSTALL in drives’ master boot record, NOT IN “/boot” partition.
Note:
This only affects older machine running BIOS firmware. Newer machines that support EFI firmware are not affect. There the bootloader doesn’t require any embeding, it’s just a regular .EFI executable file stored on the FAT32 System partition.
Most likely it was mismatch between bootloader location used by BIOS and bootloader location configured in system. But now, after MBR was overwritten, it is too late to investigate it. You should still make sure your system is actually configured to use MBR as bootloader location, otherwise you will get the same issue in the future.
There is also Bug 1156073 reported by another user with the same problem.
In the case of that user, he thought that he was booting from a partition “/dev/sda3”, but he was actually booting from the MBR. His system updated the boot code in “/dev/sda3”, because that’s what the system information said. But the grub he really used (in “/dev/sda”) was not updated.
Likely something similar was happening for you.
So now you have manually installed grub to the MBR.
You should run Yast bootloader. And if that says you are booting any other way, then change it to use the MBR there, too. That will probably install grub yet again (should be harmless). But it should also update the system information on where grub is installed. That’s to make sure that this does not happen again.
By the way, the update works fine when booting from “/boot”. I updated my laptop, which boots from “/boot”. And it still boots fine with grub 2.04.
I have just run into this error when trying to update to tumbleweed 20191130 on a BIOS/MBR/ext4 machine.
Is it fixed after that tumbleweed date?
My partition setup is as follows:
sda1 NTFS boot
sda2 NTFS Windows 7
sda3 NTFS Windows 10
sda4 Extended Partition
sda5 Linux Root with boot <- Partition is active
sda6 swap
sda7 Linux Userdata
So i boot to sda5 and from there i can boot sda1 when needed.
Or i can set the partitio sda1 active and have a windows only environment when it is needed.
The update has set partition sda1 active and neither that nor sda5 are now bootable.
How can i avoid this problem? I need grub to be in sda5 only and boot it via active partition.
As i don’t see any edit button on my post, forgive the multipost…
I have restored my machine from a clonezilla image and re-checked the setup.
In Yast i have checked the option “Write generic boot code to MBR”. This should then boot the active partition.
Also i have enabled “Boot from partition”, “set active flag for boot partition” and “probe foreign os”. Pretty standard settings for a multi-OS MBR system with grub 2.02.
Now when i update to grub 2.04, the boot partition sda1 with the the windows boot partition gets activated (see above post), sda5 gets inactivated.
And finally both partition will not boot when set to active. On both grub with the missing symbol error is shown. The windows bootloader is not coming up, when sda1 is set to active.
So either it was overwritten or the “generic code in MBR” is not booting sda correctly.
And finally as the when i set sda5 active it will also not work with the same error message of missing symbol.
How can i recover my system or avoid the situation when i update to grub 2.04?
Normally, the boot installer will not use “/dev/sda5” as the active partition. Instead, it will use the extended partition. That’s because, in principle, one is only supposed to boot from a primary partition.
As it happens, when you tell it to install generic boot code, the boot code used is capable of booting a logical partition. But it is hard to persuade the installer to get this right.
I think you have to tell to boot from a specific partition, and then specify “/dev/sda5” as that partition.
What I have been doing in those case:
DO NOT install generic boot code;
DO NOT set the active flag;
Boot from the partition “/dev/sda5”.
And then I take care of the generic boot code and setting the active partition myself. I use “fdisk” to set the active partition. And then I use the boot code “mbr.bin” in “/usr/share/syslinux”. I normally copy that to the MBR with
dd if=mbr.bin of=/dev/sda bs=440 count=1
This assumes that I am in the “syslinux” directory when doing that.
Installing generic boot code is normally a one-time thing.
Ok i’ll try to disable those options in yast and then update to grub 2.04 hoping it will not again touch the other partitions or the mbr.
Is it somehow possible to move grub from sda5 to the extended partition? I had some problems installing as i was required to keep the windows bootmgr. Unfortunately i don’t remember exactly what i did with grub to end on sda5.
This problem is misconfiguration of local system, so it is supposed to be fixed by end user on local system.
Or do you mean the problem that
The update has set partition sda1 active
? Or the problem that
neither that nor sda5 are now bootable
? These are two different problems by the sound of it and neither is described in enough details to even start guessing.
If you have image of your system and can reproduce update problem, you should open bug report collecting yast logs before and after. Also result of GitHub - arvidjaar/bootinfoscript before and after would be useful as well.
[QUOTE=connormcl;2922521Perhaps you or someone can tell me how to correct my setup so i can use grub2 2.04 on this machine?[/quote]
What exactly does not work now?
This looks pretty normal. You have grub2 in MBR and it refers to correct /boot/grub2 on sda5. You also have reference to one of your Windows instances. I would say this should work so I am not sure what exactly needs correction.
He also has grub2 in the boot sector of “/dev/sda4”, though that isn’t functional.
When he updates, it should be fine if grub is updated in the MBR. However, if instead grub is updated in boot sector of “/dev/sda4”, then he will probably run into the same problems as before.
Maybe we need to see the content of “/etc/default/grub_installdevice”.
EDIT: when partition sda1 was set to active before installing grub 2.04, the windows bootmgr on that partition came up. After installing grub 2.04 which then set sda1 active by itself, you get to the grub commandline with the missing symbol and no windows bootmgr is coming up. So it seems it has been overwritten.
Change sda4 to sda5 and update grub to 2.04?
Or
Somehow manually install grub to sda4, check it is working with current system and then updating to grub 2.04?
That file looks okay. But somehow you have grub in the MBR, whereas you should have the generic boot code there.
The grub that you currently have in “/dev/sda4” appears (from your earlier output) to not be functional.
The simplest and safest thing to do, right now, would be to reinstall grub (your current version) into the MBR. You can do this with Yast bootloader. While doing that, uncheck the box for setting the partition active. You don’t need that when grub is in the MBR.
When you have done that, recheck “/etc/default/grub_installdevice”. It should now show that grub is in “/dev/sda”.
If that all works, then the update to grub 2.04 should go well.
If you prefer a different location for grub, it might be better to wait and change that after you have it working with 2.04.
Yet another example that direct grub2-install is harmful on SUSE unless bootloader configuration is completely understood. Far too often see I advice to blindly run “grub2-install /dev/sda” without as much as even looking at current situation. This may fix booting in short term, but may also leave time bomb as demonstrated by this thread.
The grub that you currently have in “/dev/sda4” appears (from your earlier output) to not be functional.
This is likely result of restoring from backup/image. Boot block is left pointing to no more valid location. Note that location is inside sda5 partition.
The simplest and safest thing to do, right now, would be to reinstall grub (your current version) into the MBR.
If it was possible to actually reinstall bootloader it would not matter. Unfortunately SUSE does not offer any simple and straightforward way to reinstall bootloader respecting all current settings. Some options (like generic code in MBR or active partition) are one-time only and applied only by YaST the very first time bootloader is configured. They are not re-enforced thereafter. I start to think this is a bug (at least serious design shortcoming).
Usual workaround is to change bootloader to NONE in YaST, save and then select grub2 again. But it means all settings are lost in between.
I usually increase the timeout by 1 second (or reduce by 1 second). That seems to be enough of a change to result in a reinstall. I had assumed that changing to boot from MBR (instead of partition) would also force a reinstall. As to whether generic boot code is installed, or active partition is set – I wondered about that. But it shouldn’t matter if installing to the MBR.
But, yes, it would be nice if there were a more certain way of doing this – perhaps a “force reinstall” button or checkbox.