[U-Boot] efi_loader: test_efi_grub_net()
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@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/s...
I suggest that both prompts ("grub>", "grub rescue>") should be permissible.
Regards
Heinrich
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@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/s...
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).
Alex
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@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/s...
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.
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?
Best regards
Heinrich
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@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/s...
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?ex...
Just search for "grub.efi" in the file to see the command.
Alex
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@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/s...
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?ex...
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
participants (2)
-
Alexander Graf -
Heinrich Schuchardt