Re: GRUB 2.02 and APFS filesystems causing boot-time issue

2023-06-21 Thread Daniel Kiper
Hi,

On Thu, Jun 15, 2023 at 06:16:07PM -0400, vinc...@cojot.name wrote:
> 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
> Boot* 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).

shimx64.efi calls grubx64.efi from ESP. But you are right, you have to
rebuild grubx64.efi. Though it should be signed too. Or disable UEFI
Secure Boot for testing and development.

> 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... ) :)

The INSTALL file in the GRUB source should have all info which you need
to build your own GRUB binary. The upstream source code is here [1].
Please remember that (unfortunately) GRUB from Red Hat differs in many
aspects from the GRUB upstream.

If you still have any questions drop us a line.

Daniel

[1] http://git.savannah.gnu.org/gitweb/?p=grub.git=view+git+repository

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


GRUB 2.02 and APFS filesystems causing boot-time issue

2023-06-15 Thread vincent


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
Boot* 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-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel