[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GRUB 2.02 and APFS filesystems causing boot-time issue
From: |
vincent |
Subject: |
GRUB 2.02 and APFS filesystems causing boot-time issue |
Date: |
Thu, 15 Jun 2023 18:16:07 -0400 (EDT) |
Hi all,
I'm new to this list and I hope it's the right place to ask for help..
I'd like to better understand how to rebuild grubx64.efi from
upstream source so I could give a try at fixing the issue I've come
across:
https://bugzilla.redhat.com/show_bug.cgi?id=1524685
https://savannah.gnu.org/bugs/?64304
Long story short: the simple presence of an APFS filesystem on any disk in
an x86_64 system makes GRUB spit out errors (as if multiple disks were
unreadable). The machine still boots fine (after pressing 'q') but the
process requires human intervention on every reboot.
The machine in question is a Mac Pro (Later 2013) but at this point I'm
pretty sure it's a software problem since changing the partition type of
the APFS partition to something else makes GRUB happy again.
This system uses UEFI and the Linux boot entry shows this:
[root@neraka ~]# efibootmgr -v|grep shim
Boot0000* Red Hat Enterprise Linux
HD(2,GPT,d36bfc93-9920-4346-9c56-bd7c57bdb0bb,0x1000,0x3f800)/File(\EFI\redhat\shimx64.efi)
Is my interpretation of the issue correct? Something causes GRUB to get
confused when it probes/enumerates the partition and it fails in
shimx64.efi (a signed grubx64.efi rebuild)
Since shimx64.efi is a signed binary which would not possible for me to
rebuild, am I correct to think that I instead want to boot grubx64.efi an
learn how to rebuild it (with efibootmgr it would be easy to add another
entry pointing to that binary and try to boot from it).
I would love to have a few pointers, Thank you. (I've done some 'C' and
'ASM' in my past lives so I hope that will be enough... ) :)
Thank you for your consideration,
Vincent
- GRUB 2.02 and APFS filesystems causing boot-time issue,
vincent <=