Mac Pro (late 2013 model) EFI and iPXE booting

[Pretzel]

There are a pile of Mac Pros (2013 model) in my office and I would love to figure out a way to get them to PXE boot. My office uses Clonezilla to clone the workstations across a computer lab. Clonezilla Server can boot a Clonezilla client via PXE. Our old Mac Book Pros from 2008 and 2012 all have legacy BIOS boot support and can successfully boot iPXE which then boots the Clonezilla client.

Unfortunately, the new Mac Pros (2013 mode) no longer have legacy BIOS support. I called Apple tech support and checked. (as an side, Apple proposed I use Netboot to connect to a bootp server to boot iPXE to then connect to the clonezilla server to PXE boot the clonezilla client. That sounds convoluted and error prone to me.)

Ergo, EFI booting is currently the only option.

So far, I've tried downloading the iPXE source code via git and compiling the code on my Ubuntu 14.04 machine via the "make bin-x86_64-efi/ipxe.efi" command. I took the "ipxe.efi" file in the "bin-x86_64-efi" directory and renamed it "bootx64.efi" and stuck in "/EFI/BOOT" folder on a USB flash drive. When the Mac Pro boots (using the Option key), it sees this file and gives me the option to EFI Boot. But when I select it, I briefly get a black screen and then it just boots into Mac OS.

I've done a good deal of reading in this forum and it appears that this "ipxe.efi" file may not work and that I need to patch the "efi_image.c" file manually and then compile the "snponly.efi" and use that as my "bootx64.efi". Is this still true? (The posts I was reading were a few months old.)

Also, is there another way to PXE boot on an EFI only computer that may be easier?

UPDATE 2014-06-25: See the last post in this thread for the solution

[mcb30]

(2014-05-14 20:49)Pretzel Wrote:  So far, I've tried downloading the iPXE source code via git and compiling the code on my Ubuntu 14.04 machine via the "make bin-x86_64-efi/ipxe.efi" command. I took the "ipxe.efi" file in the "bin-x86_64-efi" directory and renamed it "bootx64.efi" and stuck in "/EFI/BOOT" folder on a USB flash drive. When the Mac Pro boots (using the Option key), it sees this file and gives me the option to EFI Boot. But when I select it, I briefly get a black screen and then it just boots into Mac OS.

Are you able to get to an EFI shell? If so, please try running ipxe.efi from the shell and see what error messages you get.

Michael

[Pretzel]

(2014-05-14 21:38)mcb30 Wrote:  Are you able to get to an EFI shell? If so, please try running ipxe.efi from the shell and see what error messages you get.

Negative. How would you recommend I go about doing this? (Is there a standard procedure for doing this?)

EDIT: Oh, I see that I can use rEFIt to get EFI shell access. I'll try that and let you know how far I get. I'll try ipxe.efi first.

[mcb30]

(2014-05-14 22:16)Pretzel Wrote:  Negative. How would you recommend I go about doing this? (Is there a standard procedure for doing this?)

You can get hold of the standard UEFI shell binary from https://github.com/tianocore/edk2/raw/ma.../Shell.efi.

Michael

[Pretzel]

Booting into an EFI shell from Refit, I tried this:

Quote:fs5:\> dir
Directory of: fs5:\

05/14/14 03:45p 821,312 ipxe.efi
05/13/14 01:34p 821,024 ipxe.efidrv
05/13/14 05:52p 111,808 snponly.efi
3 File(s) 1,754,144 bytes
0 Dir(s)

fs5:\> ipxe.efi

fs5:\> snponly.efi

fs5:\>

Nothing appears to have happened when running either file.

[mcb30]

(2014-05-14 23:08)Pretzel Wrote:  fs5:\> ipxe.efi
fs5:\> snponly.efi
fs5:\>

Nothing appears to have happened when running either file.

I wonder if something is going wrong very early in the initialisation process. Since the shell seems not to be displaying anything of use, you could try building ipxe.efi with DEBUG=efi_init:

Code:

make bin-x86_64-efi/ipxe.efi DEBUG=efi_init

That should give some debugging output pretty much immediately upon loading ipxe.efi.

Michael

[Pretzel]

I ran "ipxe.efi > debug.txt" and got the following results in my debug.txt file:

Code:

EFI handle 0x73c95990 systab 0x7e68ee10
EFI protocol 2f707ebb-4a1a-11d4-9a38-0090273fc14d is at 0x7c7d8b48
EFI protocol 26baccb1-6f42-11d4-bce7-0080c73c8881 is at 0x7c64ef80
EFI does not provide protocol 8b843e20-8132-4852-90cc-551a4e4a7f1c

I'm not sure how to interpret this, though.

[mcb30]

(2014-05-14 23:40)Pretzel Wrote:  

Code:

EFI does not provide protocol 8b843e20-8132-4852-90cc-551a4e4a7f1c

I'm not sure how to interpret this, though.

That GUID is EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID; it represents the EFI functionality for converting a device path into a printable representation.

Ironically, iPXE uses that protocol only for debugging purposes; before enabling DEBUG=efi_init it wouldn't even have tried to locate the protocol. You can temporarily hack around the missing protocol by commenting out the line

Code:

    DBGC_EFI_DEVPATH ( systab, efi_loaded_image_path );

in interface/efi/efi_init.c. That should get you past this particular error and hopefully will reveal what the real original problem was.

Michael

[Pretzel]

I commented out that line and recompiled and got the same result.

As an aside, do you use an IDE to navigate this code, if so, what? I just installed Code::Blocks on my Ubuntu machine and it seems pretty solid, but I don't see how to open the "project". I'd like to be able to navigate the code easily so that I can work with you.

EDIT: It looks like the problem area is on line 181 of efi_init.c where it loops over the table-entry list trying to Locate protocols. When it comes to that GUID, it exits early on line 191 with "return efirc;"

---

Ok, I added couple lines of code to get it to go thru the whole loop without exiting early and I got a new error GUID

Code:

EFI does not provide protocol ef9fc172-a1b2-4693-b327-6d32fc416042

Googling reveals this to be "EfiHiiDatabaseProtocol"

[Pretzel]

commented out the "return" function on line 191 so it doesn't return early. And recompiled and ran it. Here's the new results:

Code:

EFI handle 0x72202790 systab 0x7e68ee10
EFI protocol 2f707ebb-4a1a-11d4-9a38-0090273fc14d is at 0x7c7d8b48
EFI protocol 26baccb1-6f42-11d4-bce7-0080c73c8881 is at 0x7c64ef80
EFI does not provide protocol 8b843e20-8132-4852-90cc-551a4e4a7f1c
EFI does not provide protocol ef9fc172-a1b2-4693-b327-6d32fc416042
EFI configuration table eb9d2d31-2d88-11d3-9a16-0090273fc14d is at 0x7e4ae000
EFI image base address 0x71eba000
EFI could not get loaded image device path protocol: Error 0x7f39e083 (http://ipxe.org/7f39e083)

Thoughts?

[mcb30]

(2014-05-15 19:03)Pretzel Wrote:  

Code:

EFI handle 0x72202790 systab 0x7e68ee10
EFI protocol 2f707ebb-4a1a-11d4-9a38-0090273fc14d is at 0x7c7d8b48
EFI protocol 26baccb1-6f42-11d4-bce7-0080c73c8881 is at 0x7c64ef80
EFI does not provide protocol 8b843e20-8132-4852-90cc-551a4e4a7f1c
EFI does not provide protocol ef9fc172-a1b2-4693-b327-6d32fc416042
EFI configuration table eb9d2d31-2d88-11d3-9a16-0090273fc14d is at 0x7e4ae000
EFI image base address 0x71eba000
EFI could not get loaded image device path protocol: Error 0x7f39e083 (http://ipxe.org/7f39e083)

So, the Mac's UEFI is missing EfiDevicePathToTextProtocol and EfiHiiDatabaseProtocol. Neither of these are actually critical to iPXE's functionality: it would definitely be possible to modify iPXE to continue running if these protocols are missing.

Michael

[Pretzel]

(2014-05-16 14:59)mcb30 Wrote:  So, the Mac's UEFI is missing EfiDevicePathToTextProtocol and EfiHiiDatabaseProtocol. Neither of these are actually critical to iPXE's functionality: it would definitely be possible to modify iPXE to continue running if these protocols are missing.

I'm not entirely sure how any of this code works. Is there an IRC channel that I can pop into to work on this with you?

I'm under the impression that if I detect either of those two GUIDs in the table (and they're not supported) that they should be removed from the table. Yes?

[mcb30]

(2014-05-16 16:51)Pretzel Wrote:  I'm not entirely sure how any of this code works. Is there an IRC channel that I can pop into to work on this with you?

Yes: #ipxe on Freenode.

Quote:I'm under the impression that if I detect either of those two GUIDs in the table (and they're not supported) that they should be removed from the table. Yes?

Not quite. The EFI_PROTOCOLS table will need to be modified to provide a way to mark protocols as being optional. The code in efi_init.c will need to take the optional/required flag into account.

More significantly, the places which use EfiDevicePathToTextProtocol and EfiHiiDatabaseProtocol will need to mark their requirement as optional and be prepared to run without those protocols present. For example, the code in efi_snp_hii.c could probably just return immediately from efi_snp_hii_install() if the protocol is missing. This has knock-on effects: efi_snp_hii_uninstall() would also need to skip uninstalling the protocols (which would never have been installed). The remainder of the codebase would need to be checked for references to snpdev->hii and snpdev->package_list: these probably aren't referenced outside of efi_snp_hii.c but if they are then that code would also need modification.

Michael


Michael

[Pretzel]

Hey Michael,
I downloaded and compiled https://git.ipxe.org/people/mcb30/ipxe.g.../heads/efi and your code is a much cleaner fix than my hackery.

The code is now failing at line 224 of /interface/efi/efi_init.c

The last 3 lines of the output were:

Code:

EFI configuration table eb9d2d31-2d88-11d3-9a16-0090273fc14d is at 0x7e4ae000
EFI image base address 0x71eba000
EFI could not get loaded image device path protocol: Error 0x7f39e083 (http://ipxe.org/7f39e083)

eb9d2d31-2d88-11d3-9a16-0090273fc14d appears to be EFI_SMBIOS_TABLE (according to http://opensource.apple.com/source/Apple...SMBIOS.cpp) -- I'm assuming that's okay.




UPDATE:

---

I added the following code around line 229:

Code:

        DBGC ( systab, "efirc = %d and rc = %d", (int)efirc, (int)rc);
        DBGC ( systab, "loaded image device path GUID = %s\n", efi_guid_ntoa(&efi_loaded_image_device_path_protocol_guid));
        DBGC ( systab, "loaded image path = %p\n", loaded_image_path);

and the results I got were:

Code:

efirc =3 and rc = -2134499459
loaded image device path GUID = bc62157e-3e33-4fec-9920-2d3b36d750df
loaded image path = 0x0

Looks like RC 3 = RETURN_UNSUPPORTED, right?

---

So I commented out the "return efirc;" on line 231 and the "DBGC_EFI_DEVPATH ( systab, efi_loaded_image_path );" on line 235 and recompiled.

And it loads iPXE!

But unfortunately, the Mac Pro 2013 network card seems to be unsupported.

The EFI shell command "pci" lists two (2) "Network Controller - Ethernet controller" devices as 14E4-1682 which is the Broadcom NetXtreme BCM57762 Gigabit Ethernet PCIe card (according to this website: http://pci-ids.ucw.cz/read/PC/14e4 )

[lumps]

For the record, my older Mac Mini has the same "no network found" issue, circa 2011.

(2014-05-19 22:12)Pretzel Wrote:  Hey Michael,
I downloaded and compiled https://git.ipxe.org/people/mcb30/ipxe.g.../heads/efi and your code is a much cleaner fix than my hackery.

The code is now failing at line 224 of /interface/efi/efi_init.c

The last 3 lines of the output were:

Code:

EFI configuration table eb9d2d31-2d88-11d3-9a16-0090273fc14d is at 0x7e4ae000
EFI image base address 0x71eba000
EFI could not get loaded image device path protocol: Error 0x7f39e083 (http://ipxe.org/7f39e083)

eb9d2d31-2d88-11d3-9a16-0090273fc14d appears to be EFI_SMBIOS_TABLE (according to http://opensource.apple.com/source/Apple...SMBIOS.cpp) -- I'm assuming that's okay.




UPDATE:

---

I added the following code around line 229:

Code:

        DBGC ( systab, "efirc = %d and rc = %d", (int)efirc, (int)rc);
        DBGC ( systab, "loaded image device path GUID = %s\n", efi_guid_ntoa(&efi_loaded_image_device_path_protocol_guid));
        DBGC ( systab, "loaded image path = %p\n", loaded_image_path);

and the results I got were:

Code:

efirc =3 and rc = -2134499459
loaded image device path GUID = bc62157e-3e33-4fec-9920-2d3b36d750df
loaded image path = 0x0

Looks like RC 3 = RETURN_UNSUPPORTED, right?

---

So I commented out the "return efirc;" on line 231 and the "DBGC_EFI_DEVPATH ( systab, efi_loaded_image_path );" on line 235 and recompiled.

And it loads iPXE!

But unfortunately, the Mac Pro 2013 network card seems to be unsupported.

The EFI shell command "pci" lists two (2) "Network Controller - Ethernet controller" devices as 14E4-1682 which is the Broadcom NetXtreme BCM57762 Gigabit Ethernet PCIe card (according to this website: http://pci-ids.ucw.cz/read/PC/14e4 )

[Pretzel]

UPDATE for anyone who finds this thread:

mcb30 and I worked together over a few weeks on coming up with a solution. (He coded, I did QA/testing and feedback.) The latest release in the Master branch appears to work for me using rEFIt.

https://git.ipxe.org/ipxe.git/commit/0e3...2672e73461

This release (and presumably any release after this) should allow UEFI Macintosh machines and other UEFI machines to successfully run iPXE.

I had to compile using "make bin-x86_64-efi/ipxe.efi" myself, but perhaps there is a pre-compiled binary on the ipxe.org by now.

[goldenfri]

Thanks for this, I have been able to get iPXE started up on an xserve and it sees the network cards, but it fails to boot the image. I get the following error:
Could not boot image: Exec Format error

http://ipxe.org/err/2e0080

Mine does not have as many start up types as in the example. I only have: HTTP DNS TFTP EFI Menu

I'm thinking I might need bzImage, but I'm not sure how to include it. Any tips?

Thank you

[KingBonecrusher]

Do you need a "working" solution?

I have a working dhcpd.conf, you must only create an grub2 bootable image, but that is very easy! iPXE is also not working for me, and grub2 only with memdisk image. APPLE CRAP!!!!!

[robinsmidsrod]

@goldenfri: EFI doesn't support anything but EFI binary formats until now. There is no way to add bzImage support before the developers enable that in the source. Until now you'll have to just boot other EFI images, like vmlinuz.efi.

[kiwi66]

I managed to get a small NetBoot "nbi" bundle working which can be served from MacOS X Server to have it boot into iPXE. And I see my Xserve further attempting to load pxelinux.0 afterwards. If anyone wants the nbi bundle, I can give it to you. It works with the default efi64bit build of the iPXE (make bin-x86_64-efi/ipxe.efi)

On my test setup, a MacBook Pro (Retina) with a Thunderbolt Ethernet adapter, I can also boot but then keyboard input its not accepted. CTRL-B doesn't have any effect and it attempts to continue to boot, fails and then goes into OS X.

If anyone has a hint on how to get the keyboard working and to skip pxelinux.0 and load linux kernels directly I would be thankful. My goal at the end is to network boot our pile of Xserves to then bootstrap into Linux installers so we can run them diskless due to built in RAID controllers which are not supported by anything else than OS X (and even there they always give battery faults and other defects).