[U-Boot] efi_loader: test_efi_grub_net()
Heinrich Schuchardt
xypron.glpk at gmx.de
Sat Jul 6 09:23:07 UTC 2019
On 7/2/19 8:59 PM, Alexander Graf wrote:
>
> On 02.07.19 18:52, Heinrich Schuchardt wrote:
>> On 7/2/19 6:16 PM, Alexander Graf wrote:
>>>
>>> On 30.06.19 17:17, Heinrich Schuchardt wrote:
>>>> Hello Alex,
>>>>
>>>> the test/py/tests/test_efi_loader.py test for GRUB is failing for me. I
>>>> get the following output:
>>>>
>>>> => tftpboot 40000000 orangepi-pc/grubarm.efi
>>>> Using ethernet at 1c30000 device
>>>> TFTP from server 192.168.123.3; our IP address is 192.168.123.85
>>>> Filename 'orangepi-pc/grubarm.efi'.
>>>> Load address: 0x40000000
>>>> Loading: ###################
>>>> 1.5 MiB/s
>>>> done
>>>> Bytes transferred = 94208 (17000 hex)
>>>> => => crc32 40000000 $filesize
>>>> crc32 for 40000000 ... 40016fff ==> b51ed96c
>>>> => => bootefi 40000000
>>>> error: disk `,msdos2' not found.
>>>> Entering rescue mode...
>>>> grub rescue>
>>>>
>>>> Your script expects "grub>".
>>>>
>>>> I have been using the GRUB installed by Debian.
>>>>
>>>> I guess you expect the one from:
>>>> http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm
>>>>
>>>>
>>>>
>>>> I suggest that both prompts ("grub>", "grub rescue>") should be
>>>> permissible.
>>>
>>>
>>> grub rescue means that grub is in emergency mode because it could not
>>> find its modules. This is definitely not ok :). It usually indicates a
>>> device path issue.
>>>
>>> In your case, I'm slightly puzzled why grub would append ,msdos2 to a
>>> netboot path. But it definitely looks wrong, as it could not find the
>>> real config file (which should also reside at the tftp location).
>>
>> The Suse copy shows only 'grub>' though I have no grub.cfg on the tftp
>> server nor did I install any modules.
>
>
> It probably already embeds the "normal" module then.
>
>
>>
>> On Debian grubarm.efi is only generated when you run grub-install and in
>> the generation process it adds the the relevant partition (msdos2). The
>> Debian package itself contains no file with an .efi extension.
>>
>> Building upstream GRUB does not generate any *.efi file either. Instead
>> it behaves like Debian generating the *.efi file when installing GRUB on
>> the user chosen partition.
>>
>> I wonder if it were not preferable to have the build recipe for GRUB and
>> the binaries on a denx.de server. Do you know the path to the Suse GRUB
>> build recipe?
>
>
> The prebuilt grub.efi is mostly there to help with secure boot. It
> allows the distro to ship a self-contained grub binary that does not
> require any external modules. The build recipe for that is here:
>
> https://build.opensuse.org/package/view_file/Base:System/grub2/grub2.spec?expand=1
>
>
> Just search for "grub.efi" in the file to see the command.
The script does not add module lsefisystab. So test_efi_grub_net() in
U-Boot will fail for a GRUB 2.04 built with this script.
We should liberate U-Boot from this Suse dependency.
Regards
Heinrich
More information about the U-Boot
mailing list