Netrestore of 10.11.4 and 10.11.5 FAIL

Well I have to add one thing: while typing up the above I did a few more tests, and tried on an older MPB I had sitting on my desk for other reasons to get it to boot off of the server a handful of times off of one of the servers. It failed as expected a handful of times, but I had left it hanging while editing up the question in here.

And somehow, miraculously it seems to have popped through somehow. So the failure rate is not 100% (but given the amount of tries it's so high as to be unusable in practice. But given the lack of 100% failure rate ... could be harder to debug than needed esp. since images fail to want to boot in verbose mode (or I don;t know how to trigger verbose boot during a netstore.

Might very well be the same issue between netrestore and netinstall. That other thread seemed to focus on connections: I've the problem with both thunderbolt/ethernet apple branded adapters as well as older MPBs that still have ethernet on-board. I've no usb to ethernet adapters.

FWIW: I tried in in 2 physical locations, so 2 different networks etc. all seems irrelevant.

Thanks for the report that apple is aware of it. Now just to try to get them to finally fix it.

****: Interesting!

First off: I'm only using true Apple hardware, never have I touched anything alike a hackintosh.

Yes, one can verbose boot a mac during a netrestore, but the firmware password needs to be removed (not just entered) to do that apparently.

[a bit unhandy and waste of time, esp. if the mac has no recovery partition on it]

Verbose booting side-by side a 10.11.3 and a 10.11.5 image on relatively old macs (Last 15" pre-retina MBP and one of even a generation older were sitting here waiting to be sold)

Both end up initialising their bluetooth interface and enter it into promiscuous mode and then the difference starts:

The 10.11.3 one prints:

AppleLPC::notifyPlatformASPM - registering with plugin with ASPM Support true

followed by a long wait and then indeed something like

DSMOS has arrived

where the screen right after that goes to the graphical interface.

The 10.11.5 one prints:

NVDAGK100HAL Loaded and registered

and then seems to hang forever.

I let it hang for long enough, and then tried to disconnect it a few times from the ethernet, but none made it go on at this point. Nor were therre any kernel messages of the interface going down any longer.

Tried a second time with the 10.11.5 one: disconnected and reconnected a few times before it hangs and indeed it booted properly in the end.

<Personal Information Edited by Host>

[edit time is too short]
Tried a second time with the 10.11.5 one: disconnected and reconnected a few times before it hangs and indeed it booted properly in the end.

It did print the lines

AppleLPC::notifyPlatformASPM - registering with plugin with ASPM Support true

DSMOS has arrived

and a few more I didn't manage to capture yet after the

NVDAGK100HAL Loaded and registered

So seems it's the part that cause the AppleLPC::notifyPlatformASPM - registering with plugin with ASPM Support true to be printed that's causing the crash it seems.

And indeed a rightly timed dis/reconnect of the ethernet seems to do the trick.

Thanks to the helpful input from ****, I've been able to create a workaround:

1. Optional, but recommended: remove any firmware password the system might have.

   Boot it from either a recovery partition (if there's one), an external medium, or an OLD (10.11.3 or earlier netboot/netrestore image) to get to the tools to do that

2. Boot the system from the 10.11.5 netrestore image in verbose move from a fixed ethernet (using a thunderbolt to ethernet dongle if needed)
   Verbose mode is actually optional, but it helps a lot in your timing.
   • Hold OPTION
   • Select the image using the arrow keys
   • Hover fingers over command and V
   • press ENTER immediately followed by pressing command-V
3. At the right time disconnect the ethernet and reconnect it
   The reason and exact timing still eludes me - but it works for now ...
   • Wait long enough for the system to have mounted its new root partition - if you do it too soon, some systems will panic (retina MBPs like to do this it seems)
   • The kernel will print disconnect and connect events - if it does not anymore: you waited too long, system is already frozen- hard power off and try again
     This is also why it helps to have it in verbose mode otherwise you don't know when it froze
   • You can do it a few times - wait a bit in between.
   • Unplug the ethernet cable if you're using a thunderbolt dongle: unplugging the dingle itself seems to trigger kernel panics quite easily.
4. Remember to add the firmware password again if you removed it.

   And avoid making the same typo twice ... you do not want to "forget" that password.

Once the system switches to graphics mode: you're done, just a short wait and it'll be ready to go on as it should have without all this hassle.

I did try other combinations:

- succes, but harder to get it right on first looks: let it netrestore via WiFi with an wired ethernet connection plugged in, and unplug the ethernet at a given point (unfortunately it's still was time critical and has the added hassle of having to connect a system to the WiFi as well as it being slower that way.

- no success: using wifi only

To me this workaround allows me to image 10.11.5 instead of 10.11.3 and then upgrade all the stuff manually at the cost of not being able to do this "hands-off" anymore. The point where this is easier or not will be different for every individual and will greatly depend on volumes and/or level of non-apple sourced updates one needs etc.

I for one would appreciate more insight on timing (when's too early, when's too late for it to have effect) and what exactly this reset of the ethernet interface does to allow the machine to pass the copy protection of OS X (all on genuine Apple hardware).

In the unlikely case Apple read this: It's genuine Apple hardware, we didn't pay you to be bothered by DSMOS crap, let alone you dragging your feet to fix this.

<Personal Information Edited by Host>