Grub shipped within Fedora since 33+ to 36: some features are unavailable or broken

Ask Fedora Ask in English
, , , ,
1

Dear Fedora Community
It seems that for grub shipped within Fedora, some features have been lost or are unavailable or broken

  1. loopback command generates errors

grub> loopback loop /Fedora-Workstation-Live-x64_86-36_Beta-1.4.iso
error: ../../grub-core/kern/mm.c:376: out of memory
This error does exist for different versions of grub2 from Fedora 33 to Fedora 37
The loopback command works without error only for Fedora 32 (Whose EOL is in 1 month…) and previous versions

  1. smbios module doesn’t exist neither in Fedora Workstation .iso releases images nor in Fedora Sources Packages but is documented by GNU/Grub2 from upstream and downstream by Red Hat Bootloader Team
  2. Some recent EFI features exist but are not accessible: connectefi and efifwsetup
    So on systems with UEFI/SecureBoot activated, grub prompt does not propose any of those commands: smbios, connectefi, efifwsetup
  3. Any documentation or tools to explain how Internationalization for grub could be done in Fedora (Fr Language and Keyboard for example) is lacking

I do lack the knowledge skill and the time to file an entry in Bugzilla and I do not known how to contact the maintainers of Fedora Source Package for rpm/grub2

Since grub2 has to be signed by Fedora so that in SecureBoot on mode, shim would not hand over to grub otherwise, creating a compiled custom GNU/Grub from upstream is not feasible

Can anyone contribute and forward those elements to the package maintainers (rhboot and/or grub2) so it can be shared / discussed and maybe a link forwarded in this thread ?

Thanks for your help

2

Fedora 32 was EOL a year ago. Specifically what is your error.

3

When running:

4

Ok
I am not sure what you hope to do with that. It seems much easier to just write the image to a USB device then boot from that.

Also be aware that F36 is still beta so the iso is not the final version for release yet. Release currently scheduled for next week.

This may be worth a bug report if not already done.

5

It did prove handy over the years in case of configuration malfunction.
On the same partition it did enable to boot a fresh basic working Live fallback environment.

If thoses features where abandoned, then it should be documented.

I’ll file a bugzilla report

Thanks @computersavvy

6

You might also mention this:
https://discussion.fedoraproject.org/t/vanilla-kernel-compiled-from-source-wont-boot/20228/6
in your Bug report.

He got the same error because of a too big initramfs.

7

Hi @ilikelinux

I don’y think the problem is initramfs for my use case and convinced it’s grub package management for Fedora. The GRUB command invoked here is at a boot stage even before the kernel is uploaded to memory.

So something in the rpm/grub2 package might probably be right in Fedora 32 but later has been changed in 33 and later. I have no programming skill at all so this should be explored by Red Hat Bootloader Team and maintainers of Fedora Source Package for rpm/grub2

8

To test it, is this the correct string to add to the grub menu ?

Before we do so we need to know how to reproduce … afterwards we can make a request on Bugzilla.

9

Thanks @ilikelinux
You can put the following command line to a grub menu entry but you don’t need to. It could be simply run from the grub prompt:
grub> loopback loop /Fedora-Workstation-Live-x64_86-36_Beta-1.4.iso

To reproduce failure/bug:

  1. I have created a bootable media using standard Fedora guidelines. (The Live source image part is of no concern here).
  2. What matters is that the installer uses the version of grub shipped within the .iso file to create the file grubx64.efi in the ESP partition on location /EFI/BOOT/grubx64.efi. This is for UEFI/x64 architecture.
  3. The grubx64.efi file exists in different versions, each one related to the one maintained in Fedora Package Sources rpm/grub2
  4. You need to extract each time grubx64.efi from each package and replace accordingly into EFI/BOOT/grubx64.efi on the bootable media to test each version.

grubx64.efi from the following rpms will produce the error (tested for each version):

grub2-efi-x64-2.04-31.fc33.x86_64_rpm
grub2-efi-x64-2.06-9.fc34.x86_64_rpm
grub2-efi-x64-2.06-10.fc35.x86_64_rpm
grub2-efi-x64-2.06-29.fc36.x86_64_rpm
grub2-efi-x64-2.06-38.fc37.x86_64_rpm

grubx64.efi from grub2-efi-x64-2.04-12.fc32.x86_64_rpm is the only one without error:

grub> loopback loop /Fedora-Workstation-Live-x64_86-36_Beta-1.4.iso
This command will work just fine .

Once in grub the loopback is operational, from there, it can be used to boot directly the .iso file to a Live environment as a fallback / troubleshooting feature ( handy in a grub menuentry).

Thus for my use case, as long as I can boot the EFI/BOOT partition with a Live .iso file in it, I can launch the Live environment, test and repair when everything else (partitions, system etc…) is broken :
All what is needed grubx64.efi

Very useful to me when you can’t write a new image and/or have no other working environment at hand.

See dracut command line " iso-scan/filename" :

  Example.

       menuentry 'Live Fedora 20' --class fedora --class gnu-linux --class gnu --class os {
           set isolabel=Fedora-Live-LXDE-x86_64-20-1
           set isofile="/boot/iso/Fedora-Live-LXDE-x86_64-20-1.iso"
           loopback loop $isofile
           linux (loop)/isolinux/vmlinuz0 boot=isolinux iso-scan/filename=$isofile root=live:LABEL=$isolabel ro rd.live.image quiet rhgb
           initrd (loop)/isolinux/initrd0.img
       }

The problem is that loopback and iso-scan/filename are still existing, accessible and documented grub and dracut commands , but do not work for Fedora 33 and later.

Fedora Linux 32 is EOL in 2021-05-25 and is maintained for 392 more days which will bring us to June 2022.

  • if those to commands have decided by package maintainers to be out of date, so be it.
  • If maintainers did intend to keep them working (I sense that’s actually the case here) they should be notified of those discrepancies
  • If they are out of date, I think it should be announced somewhere or their relevant code extracted from the shipped rpms so that the commands can’t be called/accessed

I’m relatively new to Fedora I almost no programming skill, so can someone reproduce this and be kind enough to forward the relevant request ?

10

Remember fedoras policy.
Releases that are EOL no longer get updates, bug fixes, etc. As I understand it they are still available but no further maintenance of any kind occurs on those versions past their EOL date.
F32 was EOL 5/21, F33 was EOL 11/21, and F34 will go EOL 6/22.

1 Like
11

I completly agree. Nonetheless those grub command like loopback, instead of being deleted , are still accessible but do not seem to work. Looks like a bug to me. Hence my previous comment:

13

@mahdiaqallal did you ever file the Bugzilla issue? Running into the same thing with a F36 ISO (grub installed from F34) and will file a new bug report if you haven’t done so already.

14

Hi @firewing ,

Indeed I have filed the following BugZilla Issue (still unanswered) regarding topic 1:

  1. loopback command generates errors

Blockquote
Bug 2086538 - Grub shipped within Fedora 36 and since 33+: some features are unavailable or broken with/without SecureBoot"
https://bugzilla.redhat.com/show_bug.cgi?id=2086538

But is seems the Red Hat Bootloader Team is not considering such request a priority ?
Since I have found an one year old unanswered thread very similar to mine, still open in BugZilla and which relates to points 2 to 4 (see above: Grub smbios module doesn’t exist neither in Fedora Workstation):

Bug 1815924 - RFE: Include the SMBIOS module in the EFI image with GRUB 2.06
https://bugzilla.redhat.com/show_bug.cgi?id=1815924

Maybe we didn’t use the right channels to request informations or issue filing to the Red Hat Bootloader Team - (Robbie Harwood aka frozencemetery)?