This has been reported on other Linux. https://forum.endeavouros.com/t/full-transparency-on-the-grub-issue-updated-2022-08-29/30784 https://bbs.archlinux.org/viewtopic.php?id=280247 As I was trying to mess with some boot options to deal with the bad RAM I installed in the machine, I pulled in a new grub-mkconfig and version 2.12 pulled in a new segment of grub.cfg code: ### BEGIN /etc/grub.d/30_uefi-firmware ### if [ "$grub_platform" = "efi" ]; then fwsetup --is-supported if [ "$?" = 0 ]; then menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' { fwsetup } fi fi ### END /etc/grub.d/30_uefi-firmware ### It turns out that some machines the --is-supported option doesn't work and the machine would instantly get into fwsetup when you boot. I spent more than an hour trying to figure out why my machine kept getting into BIOS setup thinking it was due to a bad RAM chip I was trying to work in my machine, so I changed some options and even took the bad RAM out - and still instantly got into BIOS setup. I finally figured out there was a problem with my grub.cfg when I tried booting another bootable media that didn't have the new grub-mkconfig and narrowed it down to this code - commented it out - and my problem went away. This was extremely frustrating. This would cause a bootable system to instantly become unbootable and require another medium to repair. This would be my first grub-sourced boot failure that required alternate media to fix. I'd suggest to remove this code by default or perhaps don't bother with the fwsetup --is-supported and just add the menu entry in regardless of whether the firmware supports it or not.
The linked Arch bug implies this is the same as the issue which we have a news items for? Does it happen after following that?
(In reply to Sam James from comment #1) > The linked Arch bug implies this is the same as the issue which we have a > news items for? > > Does it happen after following that? i.e. everybody in there seems to say running grub-install works, which would bring us back to the news item.
Ah yeah you got it. It was due to not updating the core image. Oops! Changing too many things at once. It's still a bit wonky, I typed in the command wrong at first, and it ended up causing it to go to firmware setup anyway, i.e. fwsetup --is-supported-by-firmware (instead of just --is-supported) won't give an error, but will reboot and go to setup...
Reopening this; I'm going to send a patch upstream to address this.
Thanks, I'd suggest them add some command that's not an option to an existing command (with unintended side effects) so a new config would simply give a bad command error instead of getting into a state where it cannot be recovered. Technically if I could get into efishell and used its editor on grub.cfg (which I have on fat32/ESP) I could work around this problem if it happens again. However I don't know if all my EFI machines support efishell.
So I had suggested a fix for this on the grub-devel mailing list back in 2022, and it got shot down as "too complex". https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00371.html I'm afraid we are just going to have to live with this.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=597323aae87e1857d2c048dde3450e3c3c0c92c7 commit 597323aae87e1857d2c048dde3450e3c3c0c92c7 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-04-11 19:39:11 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-04-11 19:40:40 +0000 sys-boot/grub: add workaround for fwsetup issue Bug: https://bugs.gentoo.org/925370 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-boot/grub/files/grub-2.12-fwsetup.patch | 38 ++++++++++++++++++++++ .../{grub-2.12-r3.ebuild => grub-2.12-r4.ebuild} | 1 + 2 files changed, 39 insertions(+)
