Warning: Foreign fallback bootloader found.
Replace with Grub? (yes/no)
We only update fallback bootloader when it matches.
Most likely grub-reinstall might also work …
Confusion about update-grub
If you look for articles you find this:
Most expect to actually update grub to the latest version of it. grub-install --version only shows the version of the binary file to install grub, but not which grub version is installed on your MBR/EFI. For that you have to go to the grub menu or pay attention on booting your system.
update-grub is just this: Ubuntu Manpage: update-grub, update-grub2 - stub for grub-mkconfig
please can you remove kernel 5.10 ?
your motherboard is not supported with this version,
and add kernel 5.15 as i suggested here
And that’s a good thing. Only, there could also be situations where overwriting a foreign fallback bootloader is actually desired; which is why I threw those two lines into the mix for comment. Yes? No? Maybe? 
I also like the verbosity. It might even give newer users the sense that Grub is actually important.
That said, I suppose it could also enhance the ignorance. To illustrate my meaning visually, I sometimes see command output similar to this posted:
...
Rename Kcomponent to Kcomponent5? (Y/N) ...
Y
Rename Ksomething to Ksomething5? (Y/N) ...
Y
Y
Unknown command.
Y
Unknown command.
Y
Unknown command.
Y
Unknown command.
Y
Unknown command.
( Pressing Y repeatedly, without reading prompts )
Where Calamares installs grub depends on the partition layout for the target device.
If the partition layout is GPT Calamares requires you to use custom partitioning and to create an empty unformatted partition with flag bios-grub (ef02).
Calamares will tell you that such partition is required and the only way of creating it is custom partitioning.
Calamares presents choices when the boot method is BIOS and allows the user to control the loader location.
The choice is preselected - but may not be correct - thus it is easy for the uninitiated to make a wrong decision.
If the partition layout is DOS then it will install to MBR and if more than one DOS partitioned disk is available - you need to select the disk - usually the first available is preselected.
If a DOS partitioned disk - in addition to the GPT disk is present Calamares will give the choice of either.
It is quite strange that Calamares suggests to use system root (/) for the bootloader.
Even if one has created the 8B bios-grub flagged partition - the warning pops up - but allows you to continue.
I am speculating if grub is ‘clever’ enough to install to the ef02 partition type?
TEST in a VM.
I ensured there was no partitioning of any kind
sgdisk --zap-all /dev/sda
Then I launched the installer and created a custom layout using GPT with a 8MB empty unformatted partition with bios-grub flag.
A root partition with ext4 (grub select box to system root (/) )
And something has gone completely haywire when checking the partition layout after install - how is it possible the root partition has gotten a PTTYPE dos when the parttion type is clearly GPT?
$ lsblk -o path,pttype,parttypename /dev/sda
PATH PTTYPE PARTTYPENAME
/dev/sda gpt
/dev/sda1 gpt BIOS boot
/dev/sda2 dos
New test in VM
I ensured there was no partitioning of any kind
sgdisk --zap-all /dev/sda
Same custom partitioning - only change is this time (grub select box to device /dev/sda)
This time around there is no faf with the partition layout
$ lsblk -o path,pttype,parttypename /dev/sda
PATH PTTYPE PARTTYPENAME
/dev/sda gpt
/dev/sda1 gpt BIOS boot
/dev/sda2 gpt Linux filesystem
I never used the option / for the grub install. MBR is preselected but the other option available. Might be something still relevant or an issue only on 3.2 series of Calamares. Anyway the point is for gpt it is sda and not sda1 as suggested in your tutorial.
That is a Calamares thing - with BIOS/GPT you write to the partition - not the device - however as described in the manual - grub will find the partition - even if you target only the device
Caution: Be very careful which partition you select! When GRUB finds a BIOS Boot Partition during installation, it will automatically overwrite part of it. Make sure that the partition does not contain any other data.
In combination with something like a swapfile legacy setups could have just the one / partition.
Current install-grub seems to be working as intended.
$ sudo install-grub
Grub will be installed on: EFI
Installing for x86_64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-linux-amd-znver3
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux-amd-znver3.img
Found initrd fallback image: /boot/initramfs-linux-amd-znver3-fallback.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
Adding reboot option.
Adding poweroff option.
done
Then why is Calamares calling sda instead of sda1 and the install is still booting? I might have overlooked it but couldn’t make it out in the Ubuntu scripts of the grub package either.
https://wiki.archlinux.org/title/GRUB#GUID_Partition_Table_(GPT)_specific_instructions
When grub is installed onto a gpt partitioned disk it looks for an unformatted partition 0xEF02 or GUID=21686148-6449-6e6f-744e656564454649.
If it finds such partition it will use it - ortherwise it will or should I say it should fail to install.
When you boot a BIOS system - like a VM you have no partition table - thus selecting auto Calamares will create a BIOS/NBR layout.
If you choose manual partition and opt to create a GPT partition layout - you will be prompted that such system requires a bios-grub partition to exist.
As stated in the grub manual a GPT disk does not have a MBR - the first 1023B is used to protect the disk from being overwritten. It even contains Hah!IdontNeedEFI
https://wiki.archlinux.org/title/GRUB#GUID_Partition_Table_(GPT)_specific_instructions
Well all the guides I find on grub install on BIOS/GPT tell the user to have that unformatted partition with flag to store core.img but always specify the disk and not a partition when calling grub-install.
That is likely correct - because grub will use the first partition with partition type being 0xEF02.
GPT specification allows for several partitions of the same type to exist side by side - but what happens if there -for any reason - is two - and your system is actually using the first for one system and the second for another?
In such case you need to specify the partition to use - and that is why I included the partition - to exclude misinterpretation and misunderstandings.
Yes - targeting the disk is likely to work as expected when only one 0xEF02 partition exist because grub is smart enough to look for it.
I can rephrase the section in the primer topic - just have think to make it logical without being technical.
1 Like
From Rod Smith:
GPT fdisk can create the EFI GPT (0xEE) placeholder partition either before or after the hybridized partitions in the MBR table. (Note that this has nothing to do with the disk sectors this partition protects.) Each placement has its advantages. Putting the 0xEE partition first in the table works best with GRUB Legacy and GRUB 2, which treat the disk as an MBR disk if the first slot in the MBR is not a 0xEE partition.
Could your first test show that the Protective MBR was somehow positioned last in the table, and appears as dev/sda2 (dos)?
After a lot of digging, reading manual pages and scanning image files I have found the following
$ man grub
[...]
INSTALL_DEVICE must be system device filename. grub-install copies GRUB images into /boot/grub. On
some platforms, it may also install GRUB into the boot sector
[...]
As others has discovered - grub documentation is not clear on how to address the bios-grub partition or if it is even necessary.
I will do some further research into this - in the meantime I have edited the primer section - informing more research is needed.
There is a lot of info to be found on the topic and from some of it refers to the GPT bios-grub partition as a replacement for the MBR gap.
Search for grub bios gpt install to device or partition - sx.nix.dk
On a BIOS/MBR setup the loader is written into the post-MBR gap but on GPT partitioned devices that GAP may not be big enough - according to grub manual certain file systems may limit the available space - making it necessary to create the bios-grub partition.
Since I can find references to installing grub on a partition - there may have been a shift in how grub handles this.
If I install without a bios-grub - as you also found - the system boots equally well - grub must have some special logic making the jump to core.img possible without a bios-grub partition.
What have I learned
What I can say I have learned until now is that pointing the grub-install command for BIOS/GPT to the base device e.g. /dev/sdy is more correct than using the partition with the 0xEF02 identifier.
In any case the boot.img is written into the the first 512 bytes of the protected MBR of the selected disk.
If the partition is available the core.img is written to the partition and in case more than one - it will use the first partition with the 0xEF02 identifier.
If the partition is not available grub uses some internal logic to search out the core.img from the device where the boot.img is loaded from.
Hey @philm
This command you mentioned in the Topic:
$ sudo pacman -S grub
Is this command only needed for us to check if we see errors by a manual start now?
Is this script designed to always stay in background and it will be triggered till we downloaded another Release Version that included new Grub version and automatically doing its job in the background.
Or is it required after every release version to manually going in Terminal and type $ sudo pacman -S grub from now on?
Yes, the hook says exactly that:
[Trigger]
Type = Package
Operation = Upgrade
Target = grub
[Action]
Description = Installing Grub to MBR/EFI
When = PostTransaction
Exec = /usr/bin/install-grub
So you only need to install it, obviously keep it updated, and viola!
1 Like
Failing here saying WARNING: EFI directory not found! Grub couldn't be installed.
The main reason is that
> find /boot -name grubx64.efi
/boot/efi/EFI/manjaro/grubx64.efi
Whereas the script is grepping for Manjaro (with a capital M that I don’t have in the path from a live-installer install in november)… The joys of vfat and case [in]sensitivity I guess…
so I guess a grep -i "$bootloader_id" is required insteadof a grep "$bootloader_id"
2 Likes
Latest version of script is working to remove /etc/grub.d/30_uefi-firmware for MBR
I have also deleted /etc/grub.d/30_os-prober to get rid of the warning message about os-prober
Most users don’t even know how grub got installed to begin with.
I know that grub is installed to MBR from recent check of calamares on new ISOs
some users can check calamares log
sudo cat /var/log/calamares.log | grep 'grub-install'
but my log is from 2017 and drives have been changed a few time since then
users could also check drive and partition information: inxi -DPa
and other users can also help new users if they have posted system information
Hmm, what you mean with keep it updated?
Keep it update = just keep doing downloading stable release version?
or keep it update with manually execute: $ sudo pacman -S grub so it still needs a little manual intervention?
How do you normally keep your system and packages up to date?
sudo pacman -Syu