"Chainloading Failed" on iPXE-Boot

[tian]

We’re currently experimenting on cloning Apple/iMacs with fog.

The PXE boot seems to be fine already and iPXE is loaded (Also the entry in the mac’s boot menu is there - twice which seems not to be a problem).
But at the end of the iPXE Process it won’t continue and stops with “Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds”:

We first tested with fog version 8301 and updated today to 8329 but the problem remains.

Here are some of the iMac’s data that might be important:

• iMac14,2 (late 2013), Intel Core i5 3,2 GHz, Boot-ROM-Version: IM142.0118.B13
• NIC: Broadcom 57766-A1, Firmware 57766a-v1.15

If there are any more information (from logs, hardware, iPXE shell…) needed I can get them.

[Tom Elliott]

Please update to lastest.

[tian]

With version 8341 it is still the same.

[Tom Elliott]

When you see the error, is there anything in the apache error logs on the server?

[Sebastian Roth]

@tian Please open that URL (http://x.x.x.x/fog/service/ipxe/boot.php) in your browser and copy/paste the full content here in the forum (change IPs if you like but please post the full content).

[tian]

@tom-elliott

I found something in other_vhosts_access.log:

%fog_ip%:80 %imac_ip% - - [30/Jun/2016:15:29:21 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 432 "-" "iPXE/1.0.0+ (7156)"

The error.log and access.log didn’t contain anything from the time pxe-booting the iMac.

@Sebastian-Roth said in "Chainloading Failed" on iPXE-Boot:

@tian Please open that URL (http://x.x.x.x/fog/service/ipxe/boot.php) in your browser and copy/paste the full content here in the forum (change IPs if you like but please post the full content).

#!ipxe
set fog-ip %fog_ip%
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
iseq ${platform} efi && set key 0x1b || set key 0x1b
iseq ${platform} efi && set keyName ESC || set keyName Escape
prompt --key ${key} --timeout 3000 Booting... (Press ${keyName} to access the menu) && goto menuAccess || sanboot --no-describe --drive 0x80
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param username ${username}
param password ${password}
param menuaccess 1
param debug 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar http://%fog_ip%/fog/service/ipxe/boot.php##params```

[Tom Elliott]

What bootfile are you using? I’m not sure that Mac can work using hidden menu.

[Tom Elliott]

Also, you might try updating again? I doubt it will help, but it should ensure your hosts get seen properly.

[tian]

We’re using the “fancy version” (https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC#fancy) with ipxe.efi to get pxe-boot working with the iMac. - The DHCP server is not the fog-server itself but also a Linux based server.

(Version 8343 still has this problem.)

[Tom Elliott]

Can you edit the boot file to come out of the i386-efi/ipxe.efi rather than just ipxe.efi? I, again, doubt it will work, but just trying to see what’s going on in the first place. Can you also disable (for now) the hidden menu just to ensure it’s not something lacking that hidden menu is requesting?

[tian]

I deactivated the entries for “Hidden Menu” and “No Menu” and the menu appeared. But I activated both entries again because the “Chainloading failed” message does not appear, when a task is planned for this client. I tried the hardware inventory and capturing task - both tasks still seem to have some other problems on the iMac, but at least they are beginning to run/start. Sorry for the inconvenience and for not testing this simple thing first…

Since it is just a appearing, when booting from network without a planned task it should be no problem for the iMacs since we would have to net boot them manually every time.

Thanks for your effort.

[Sebastian Roth]

@tian said:

Since it is just a appearing, when booting from network without a planned task it should be no problem for the iMacs since we would have to net boot them manually every time.

Do I get this right? You are netbooting you iMacs by hand every time you want to image those? Hope you have read this (although I still do not prefer this method, others might like it)!

[tian]

@Sebastian-Roth
By “manually” I meant pressing the “n”-key or “alt” key for direct network boot or the apple boot menu. The next-server and filename are already delivered by our DHCP server automatically.

But for now it would be fine like it is. If we decide to use Fog for deploying our iMacs too it would be no problem to start a deployment task and press the keys, since it is only one classroom. It is not that necessary to set the network boot as default.

If needed I also could do some additional testing (e.g. with the EFI Exit Types) when I have some time.

[For the other problems I already opened other threads.]

[Tom Elliott]

Anybody have any ideas for this? @tian I know you’re trying, but this is so far specific to Apple Mac systems, correct?

[tian]

@Tom-Elliott So far it is appearing on the Mac-System we maybe want to use fog with in the future.
I tried some more (now Version 8581) with the exit types and “REFIND_EFI” is working - instead of the “Chainloading failed” message a blue Refind screen appears for less then a second and OSX booting continues without the 10 seconds delay.

Currently we also use the trunk version for testing normal PCs for quite some time - but these don’t have EFI. I’ll ask my co-worker if he still has the older iMac (2007 Model I think) I used for testing PXE by the bless command a long time ago (Fog 1.20?) - because I don’t remember a “Chainloading failed” message back then.

[Tom Elliott]

I’ve update the iPXE files and I believe I finally figured out the efi files getting the chainloading issue. Of course I won’t know if it is actually working until somebody tests and lets us know the status.

I believe the errors were not a bug on iPXE (directly) but rather the configuration that needs things was not happening properly. Because the ipxe scripts as they’re sent to the user have some needs, but the efi files did not have those “needs” I think you would see the chainloading error simply because it couldn’t run that particular command. (What command that was I have no clue).

[tian]

@Tom-Elliott Today we tested with Version 1.3.0-RC-1 (SVN Revision: 5935) and the “Chainload failed” message still appears with exit type “EXIT”.

But since the exit type “REFIND_EFI”works, we’re OK with that.