Issues with GRUB on the unstable branch


Got greeted by this beauty on kernel 5.19. This time I got the “out of memory” errors without trying to access the GRUB menu. I guess shutdown and reboot aren’t the same for the system, since this booted just fine yesterday, when all I did were reboots after updates.
Booted to 5.15, downgraded GRUB, and everything is back to normal (absence of “out of memory” errors, and working theme included).

I have been thinking in the same direction - thought it could be the kernel.

I dug around in the jammed laptop but I couldn’t find any hints to why grub should fail and force me into the firmware.

As this is playground and this topic already contains a reference to archlinux reddit - I thought - I test a vanilla Arch - replacing my jammed EOS.

The Arch grub has an epoch attached and there is no issues with

$ uname -r
5.19.3-arch1-1
$ grub-reboot --version
grub-reboot (GRUB) 2:2.06.r322.gd9b4638c5-1

My working Manjaro is

$ uname -r
6.0.0-1-MANJARO
$ grub-reboot --version
grub-reboot (GRUB) 2.06.r322.gd9b4638c5-1

Arch users are having issues as well:

FS#75673 - [grub] long(er) start delays after upgrading from 2.06.r261 to 2.06.r297

1 Like

I saw that - the interesting bit is that my test of EOS was working with r297 - but jammed with r322 - and no indications at all.

I checked in chroot - with mkinitcpio and grub-mkconfig - thought it could be - I don’t know - a grub to kernel that failed - but nothing I could find.

Which is why I decided to do a clean vanilla arch using an arch iso and archinstall - which is working but grub appear to have been rebuiltf - the epoch being 2 comparing to the earlier EOS on r297 - which had no epoch and now grub is epoch 2 - someone has been busy in arch camp.

uname -r           
6.0.0-1-MANJARO 
grub-reboot --version 
grub-reboot (GRUB) 2.06.r322.gd9b4638c5-1

no issues too

i hope this not coming from compiled GCC 12 , there was a report on kernel 5.19.3 about
Grub ( see grub.git - GNU GRUB)

on report archlinux , it seems to concern AMI Bios , not phoenix Bios ,
can we confirm that point ?

Even after forced downgrade by package system from 322 to 261 my laptop got bootlooped to bios. Your instruction helped to restore.

Guess I spoke to soon seems latest update and reboot went to bios.

To everyone who brings up making backups which I’m bad about not doing thanks for bringing that up.I rebooted into the latest Manjaro live usb restored the backup with timeshift from yesterday rebooted and reinstalled grub which downgraded to 261 then ran updates rebooted and all’s well.Again thanks for stressing about making backups. :smiley:

Arch packagers are currently working diligently on the issue. See FS#75701 - grub 2:2.06.r322.gd9b4638c5-1 issue

Thanks to @dalto for writing up an EndeavourOS blog post with more info about the issue:

1 Like

there is not enough full testing from git savannah Grub , there are many commits since release 2.06

Well we should slow down in blindly adopting grub updates when Arch does it. In the end it is grub-git what Arch is pushing out to their users without much testing. Also most already adopted systemd-boot or other bootloaders so grub is in general not great tested with Arch. At least we should check the commits for breaking changes.

The issue

Starting with this commit, grub introduced a call to fwsetup --is-supported in /etc/grub.d/30_uefi-firmware. If the version of grub you have installed via the grub-install command didn’t support that command, it caused grub to fail.

Prior to the most recent version, grub only registered the fwsetup if detected support. If your machine detected support, you would have had the fwsetup command registered and the failure wouldn’t occur.

In other words, BIOS installs seem to work as the change was done for UEFI ones only.

Why does it happen?

When you update the grub package you won’t update our installed grub bootloader on master boot record on your system. So when you installed Manjaro years ago that version of grub doesn’t support the cmds the updated scripts might try to execute. Only when a newer version of grub got installed via grub-install those cmds get supported. A smarter move whould have been to check if the actual installed grub supports newer cmds scripts may blindly execute.

Grub itself is mostly installed once and forgotten. Only if there are really security risks it is recommended to reinstall grub also to your Master Boot Record (MBR).

4 Likes

Luckily there is an unstable branch which shielded the issue for 95% of users.
Maybe it’s better not to include always the latest and greatest version for such a vital piece of the chain.

1 Like

Also most already adopted systemd-boot or other bootloaders so grub is in general not great tested with Arch

Has the manjaro team ever considered adopting systemd-boot as default instead of grub? Feature-wise they are about the same, innit?

Not sure if will not take a lot of effort for those with BIOS systems systemd-boot - ArchWiki

I wondered that because last time I checked archiso archinstall script defaults to N for using grub. Don’t know if it’s changed, tho.

Come from this error:

I tried what you says, but no luck:

sudo manjaro-chroot -a
==> ERROR: No Linux partitions detected!

Thanks all for the explanations, but could you tell me what are the next steps for the next stable releases ?

What are the recommandations ?

I am on the stable branch with grub 2.06.r261.

Will there be a workaround ?
How to know if i am impacted with this issue in my system?

Thanks

Currently all branches are using r261.
It will be updated once a working solution is found.

If no solution is found its not that difficult. From what I’ve read you just need to install /update grub after the update before you reboot.

It’s obviously going to cause issues for users that don’t read the announcement thread but for everyone else it’s a very simple fix

2 Likes

Interesting thing is that I started this thread about issues I got, even though I did install and update GRUB after the package updated. I didn’t get the seemingly usual symptom of booting into UEFI, I got a good ol’ kernel panic.