Grub update stopped 32 bits systems from booting

[pemartins]

rEFInd does boot the Oss but through the others pre-existente grub menus. In example it shows Ubuntu grub menu, MX grub menu, Windows grub menu and I'm able to boot Oss going from rEFInd to Ubuntu menu and then booting whatever the Ubuntu menu has in there.

If there's a place with a simple tutorial on how to use rEFInd I'd love to learn about it. To be honest I did find extensive documentation about it but it was not noob friendly, apart from the auto install there wasn't much that I understood.

I'd also like to learn how to remove old boot entries left by uninstalled OSs, I found out I have a lot of them.

- - -

But now concerning the original issue, I just did a restore of an old backup I had, did a "sudo grub-install" and it worked, the issue was no longer there and the 32 bit Android-x86 based OS booted. The issue went away and all worked great as it used to do.

I'm marking this one as solved nevertheless.

Thank you all for the help.

[jlittle]

I'd also like to learn how to remove old boot entries left by uninstalled OSs, I found out I have a lot of them.

There's two places that junk entries can pile up.

1. The EFI non-volatile storage variables. You can use the command line efibootmgr utility to look at these. Here you may be at the mercy of a buggy UEFI implementation; my Kubuntu system's Gigabyte mobo sometimes generates lots of spurious junk when it feels like it, especially after plugging in a bootable USB. efibootmgr can delete them, though the interface is horrible. The firmware itself should let you clean them up, too. For this my system's firmware is much easier to use, it even has mouse support, but it's buggy and doesn't work a lot. Be sure not to delete the entries your system uses, and use

   $ sudo efibootmgr -v

   to identify the "images", .efi files, being used, which will inform what not to delete in 2...
   
2. The EFI partition has a file system like any other. Maybe rEFInd is finding stuff in there. Normally, *buntus install to /boot/efi/EFI/ubuntu/grubx64.efi (or maybe shimx64.efi with secure boot). You can go in and clean up. By default, you need root access to do so, but I edit the /etc/fstab entry for /boot/efi to have "umask=000" in the options, so any user has access and I can use dolphin to delete stuff.

[pemartins]

Ok finally this issue has been identified, it is no more than someone who screwed up big time and, by some impossible reason to be understood by the common mind, decided that 32 bits systems were not to be booted anymore in a computer that uses an updated grub (which is 64 bits).

The bug is reported here:
https://bugs.launchpad.net/ubuntu/+s...2/+bug/1876737

the 'illuminated' offending line is this one (2105):
https://git.launchpad.net/ubuntu/+so...fi.patch#n2105

and as a workaround a solution is to get the grubx64.efi from here:
http://archive.ubuntu.com/ubuntu/dis...amd64/current/

and replace as root the one at:
/boot/efi/EFI/ubuntu/grubx64.efi

[jlittle]

and replace as root the one at:
/boot/efi/EFI/ubuntu/grubx64.efi

Note that a grub update will overwrite this. Here's two ways to stop it:

1. Adjust the /etc/fstab entry for /boot/efi to have "noauto,user" in the options. This means Linux won't mount it at startup, but will let you mount it when you want to. When a grub update arrives, it can't overwrite your grubx64.efi.
2. Copy the /boot/efi/EFI/ubuntu directory and its contents to, say, /boot/efi/EFi/pemartins, and use efibootmgr to create a boot entry that points at it, and put it first in the boot order. A grub update might change the boot order, but you can run

   sudo  dpkg-reconfigure  grub-efi-amd64

   to tell it not to update the NVRAM and stop this; be warned that this command triggers grub to update! A release upgrade (f.ex. focal to groovy) will still mess with the boot order.

I do both, but doing only 2. has the advantage that it lets grub update the EFI/ubuntu/grubx64.efi to keep it up to date. I update it only every few years; if a boot works, it tends to keep working. (With grub's updates, I've found it tends to stop working unpredictably.)

[pemartins]

Great idea @jlittle I shall do so. Please help me out with this part:

...and use efibootmgr to create a boot entry that points at it

How exactly can I do that?

In my uefi the grub entries for the Android-x86 based operating systems do not show, the only way I can make them show is by using an application for Windows called EasyUefi (if I'm not mistaken); I had no idea that efibootmgr could do such a thing, it would be really helpful for me to know how!

Thank you very much for your help!

[jlittle]

Great idea @jlittle I shall do so. Please help me out with this part:

and use efibootmgr to create a boot entry that points at it

How exactly can I do that?

Assuming the ESP is on /dev/sda, and the name "pem" is suitable:

sudo efibootmgr -c -d /dev/sda -l '\EFI\pemartins\grubx64.efi' -L pem

I find the efibootmgr command clunky and awkward. But here's my cheat sheet:

# list the boot entries
sudo efibootmgr
# list the boot entries with details
sudo efibootmgr -v
# delete Boot0003 (-B means delete? what?)
sudo efibootmgr -b 3 -B 
# set the boot order to be Boot0001 then Boot0000
sudo efibootmgr -o 1,0

In my uefi the grub entries for the Android-x86 based operating systems do not show, the only way I can make them show is by using an application for Windows called EasyUefi

I'm out of my depth now, I think. If the Android-x86 OSs have they're own .efi executables, then once you're running the grub .efi, then maybe grub could chain to them, like it does to the Windows boot loader.

But by "Grub entries", do you mean grub doesn't find those OSs when it's generating the menu (that is, sudo update-grub), or you've added entries (via /etc/grub.d/40_custom or /boot/grub/custom.cfg) and they don't show? See this Arch thread for an example of the latter.

For what may be a Linux equivalent to EasyUefi, check out rEFInd (sudo apt install refind). I haven't used it, but others here at KFN have praised it.

[pemartins]

Brilliant @jlittle, that efibootmgr guide was indeed gold for me, thank you very much!
Done and tested, all is fine and with no more worries of having another bad surprise if another grub update 'bug' comes along.
This was really helpful for me, both for the thread issue and for the Android-x86 OSs.

Yes Android-x86 OSs have what looks like a regular Linux grub and it creates an Android folder in EFI. But, by some reason, in some laptops including mine it shows neither on the uefi list neither it is recognized to chain with other Ubuntu grub launchers.
So until now I needed to use that Windows app I mentioned to indicate the grubx64.efi file so that the uefi menu for Android-x86 booting was to be created.
As far as it showing in the Ubuntu grub, doing it by hand is the only way that I could manage, either by entering the grub code in 40_custom or by adding it on Grub-Customizer.

Again I thank you very much for your help!