iPXE discussion forum

Full Version: iPXE Block IO stub breaks grubnet
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I am having the exact problem described here: https://lists.gnu.org/archive/html/help-...00082.html

However, I am using grub2netx64.efi from Solaris and it's going to be a lot harder to get Oracle to work on a fix for this iPXE particularity.

Below is a description, from the Ubuntu patch, of what causes the problem:

Subject: [PATCH] disk/efi: skip iPXE dummy block devices
iPXE adds Simple File System Protocol to loaded image handle, as side
effect it also adds Block IO protocol (according to comments, to work
around some bugs in EDK2). GRUB assumes that every device with Block IO
is disk and skips network initialization entirely. But iPXE Block IO
implementation is just a stub which always fails for every operation
so cannot be used. Attempt to detect and skip such devices.

And a comment on the nature of the fix:
We are using media ID which iPXE sets to "iPXE" and block IO size in
hope that no real device would announce 1B block ...

The fix is:
--- a/grub-core/disk/efi/efidisk.c
+++ b/grub-core/disk/efi/efidisk.c
@@ -80,6 +80,14 @@ make_devices (void)
/* This should not happen... Why? */
continue;

+ /* iPXE adds stub Block IO protocol to loaded image device handle. It is
+ completely non-functional and simply returns an error for every method.
+ So attempt to detect and skip it. Magic number is literal "iPXE" and
+ check block size as well */
+ if (bio->media && bio->media->media_id == 0x69505845U &&
+ bio->media->block_size == 1)
+ continue;
+
d = grub_malloc (sizeof (*d));
if (! d)
{


Since I have little to no hope of seeing a similar fix from Oracle any time soon, can anyone suggest a workaround I can use?

Thanks.
Darie
It seems that grub is making things more and more unusable.

Tip is to not use grub at all.

What grub should do is to read efifs properly so that files can be loaded in iPXE via initrd.

There is already some discussions about what grub should do on the mailing list.
I need to chain to Solaris 11 Automated Installer, so I don't think I have a choice but to use grub2.
Can you suggest how I could workaround the 1B stub being perceived as a disk?
Why do you have to use grub?
Using grub, the "Solaris 11" menu item just chains to the Solaris Automated Installer grub2netx64.efi which has everything pre-configured and works.
If I don't use grub, first I have to figure out how to convert the following grub2 entry into an iPXE menu item:

menuentry "Oracle Solaris 11.3.25.3.0 Automated Install" {
set kern=/solaris11_3_25-i386/platform/i86pc/kernel/amd64/unix
echo -n "Loading ${root}$kern: "
multiboot2 $kern /platform/i86pc/kernel/amd64/unix -B install=true,install=true,install_media=http://\\$serverIP:5555//export/auto_install/solaris11_3_25-i386,install_service=solaris11_3_25-i386,install_svc_address=\\$serverIP:5555
set gfxpayload="1024x768x32;1024x768x16;800x600x16;640x480x16;640x480x15;640x480x32"
insmod gzio
echo -n "Loading ${root}/solaris11_3_25-i386/platform/i86pc/amd64/boot_archive: "
module2 /solaris11_3_25-i386/platform/i86pc/amd64/boot_archive
}


get the video properly set up:

function load_video_i386_pc {
insmod vbe
}
function load_video_x86_64_efi {
insmod efi_gop
}
# end preamble
load_video_$target
terminal_output console


and hope that all the Solaris particularities don't prevent it all from working, blocking my progress just a bit further after a lot more work.
and incidentally, if I don't chain to the grub2netx64.efi, I no longer have a reason to be using iPXE. That's the problem it resolves for me.
(2017-12-05 11:20)eterle Wrote: [ -> ]Using grub, the "Solaris 11" menu item just chains to the Solaris Automated Installer grub2netx64.efi which has everything pre-configured and works.
If I don't use grub, first I have to figure out how to convert the following grub2 entry into an iPXE menu item:

It's something of a hack, but you can probably work around this by using wimboot. This will expose a virtual FAT-formatted disk constructed from the files previously downloaded by iPXE. GRUB will be able to load the files from this virtual FAT filesystem.

Your boot chain would then be:
  • iPXE downloads wimboot plus the relevant Solaris files via HTTP (or whatever other download mechanism you want to use)
  • iPXE exposes an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL containing a virtual filesystem containing the downloaded files, and executes wimboot
  • wimboot exposes an EFI_BLOCK_IO_PROTOCOL containing a virtual FAT-formatted disk containing the files exposed by iPXE, and executes GRUB
  • GRUB loads the files from what it believes to be a FAT-formatted disk

Michael
I don't suppose there's a way for me to make a boot.ipxe which doesn't add the Block IO protocol stub?
(2017-12-06 10:28)eterle Wrote: [ -> ]I don't suppose there's a way for me to make a boot.ipxe which doesn't add the Block IO protocol stub?

Only by patching the source code.

Michael
Is the Block IO protocol stub really necessary?
As per my original post the addition of Block IO protocol is a "side effect" of adding Simple File System Protocol.. I'm not much of a coder, can someone suggest what might work?

Thanks.
Darie
Reference URL's