Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sanboot 0x80 (local) on EFI
2018-02-13, 00:06
Post: #1
Sanboot 0x80 (local) on EFI
Hello,
I have an EFI dual-boot setup. (One disk with GPT partitions, including an EFI partition) I'd like to be able to boot locally, and to choose which .efi file to boot. As such, simply using 'exit' will not serve my purposes.
I have iPXE on a USB flash drive. (I've tried both 64-bit EFI and BIOS as well as the default 32-Bit BIOS.)

I expect the command:
Code:
sanboot --filename \efi\path\to\file.efi --no-describe --drive 0x80
to work. However, this simply states that the sanboot device cannot be found in EFI mode (2c222087) or that there is an Input/Output error in BIOS mode.

I've found very little documentation on this issue, with most people opting for the 'exit' method. I found somewhere that it could relate to EFI systems not working with sanboot, but then I see in the documentation that the '--filename' argument is specifically for EFI systems. So this leaves me a bit confused.

If anyone has any advice or suggestions, I'd be very open to hearing them.
Thanks!
Visit this user's website Find all posts by this user
Quote this message in a reply
2018-02-13, 06:35
Post: #2
RE: Sanboot 0x80 (local) on EFI
If your machine has 64bit efi firmware then you won't be able to boot a 32bit version of ipxe efi

So first make sure that you are referring to the correct ipxe binary and mode as to not confuse this further.

If you are using a pcbios build of ipxe then filename will do nothing.
That sanboot command will boot the first "EFI disk" with the filename you provide, so using exit 1 would do that for most cases when the disk is next in boot order. One step in trying to figure out how your system maps things would be to use a efi shell.

Also, always read and post the ipxe.org error urls. http://ipxe.org/err/2c2220 have 2 possible sources in the code, either no network device is open, or it simply can't find the disk. So make sure you have ifopen or dhcp before sanboot, and if that fails build ipxe with DEBUG=efi_block to get more details on what it fails on...
For reference commit where the --filename was implemented: https://git.ipxe.org/ipxe.git/commitdiff...e4b58cacc8

iPXE is a network boot program, not local disk boot program so booting from disk is not the intended use.

Use GitHub Discussions
VRAM bin
Visit this user's website Find all posts by this user
Quote this message in a reply
2018-02-13, 16:20
Post: #3
RE: Sanboot 0x80 (local) on EFI
(2018-02-13 06:35)NiKiZe Wrote:  If your machine has 64bit efi firmware then you won't be able to boot a 32bit version of ipxe efi

So first make sure that you are referring to the correct ipxe binary and mode as to not confuse this further.

If you are using a pcbios build of ipxe then filename will do nothing.
That sanboot command will boot the first "EFI disk" with the filename you provide, so using exit 1 would do that for most cases when the disk is next in boot order. One step in trying to figure out how your system maps things would be to use a efi shell.

Also, always read and post the ipxe.org error urls. http://ipxe.org/err/2c2220 have 2 possible sources in the code, either no network device is open, or it simply can't find the disk. So make sure you have ifopen or dhcp before sanboot, and if that fails build ipxe with DEBUG=efi_block to get more details on what it fails on...
For reference commit where the --filename was implemented: https://git.ipxe.org/ipxe.git/commitdiff...e4b58cacc8

iPXE is a network boot program, not local disk boot program so booting from disk is not the intended use.

Thanks, NiKiZe
So to clear things up, I'd tried the following:
32-Bit BIOS (Since it's the default build.)
64-Bit BIOS (I built this third just to try it, not expecting it to work.)
64-Bit EFI (My original intention, this I'd expect to work)

The 64-Bit EFI build is the build that is not seeing a SAN device 0x80. I'd guess the other two just can't boot because they don't know what to boot without specifying the .efi file, which of course doesn't work for BIOS mode.

The issue with using exit 1 for me is that I need to specify which .efi file in the efi partition to boot. (There's one to load Linux and one to load Windows) I'd like to send a script over the network which will specify either .efi file depending on needs. But I do understand booting locally might be a bit clunky as it seems more to be a byproduct than an implemented feature given the intended nature of the software.

Per your comment about how the system maps things, do you mean directory structure or something else? I know where in the efi partition the .efi files are located and I know that the efi partition is located on fs0. (And I've booted the two files from the efi shell previously)

As far as not finding the disk versus networks, I'm pretty sure I had a network connection when I tried running this command, but I can go and double check later. (There's a tiny chance I had the cable unplugged in all cases, but I doubt it.) In either case, I wouldn't expect that to matter, but then I don't claim to be an expert on this software. I know I've managed to successfully download from a host using iPXE, which is good. As far as not finding the disk, that I'd expect would be an issue.

I'll try the debug build when I have a chance today. (As well as ensure I have the network connected) I'll update with anything I find. Thank you again!
Visit this user's website Find all posts by this user
Quote this message in a reply
2018-02-13, 20:31 (This post was last modified: 2018-02-13 20:31 by PMiller96.)
Post: #4
RE: Sanboot 0x80 (local) on EFI
I tried again ensuring a proper connection and with the debug build. I received the following:
Code:
Booting \efi\path\to\file.efi from SAN device 0x80
EFIBLK cannot find drive 0x80
Boot from SAN device 0x80 failed: No such device (http://ipxe.org/2c222087)

I don't remember seeing the part about EFIBLK before. So perhaps that is relevant.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)