NetSUS 4.1.0 - unable to NetBoot 2017 USB-C iMacs

[dj2017]

I have a 10.12.6AutoCasperNBI image which boots up older iMacs using NetSUS 2.x and 4.1.0. That is, up until the USB-C iMacs. When a USB-C iMac starts up, I can see the NetBoot disk available, choose it, then the machine sits with a black screen for a bit, then boots to the hard disk again. However, if I attach a USB-C to USB-A adapter, then an old Apple USB-A to Ethernet adapter, I can then NetBoot the USB-C iMac. Which it does successfully, albeit very slowly. That is, the operating system in the NBI is fine for this model. The same OS package, created with AutoDMG, and used to build the NBI, can also be laid onto the machine and boot it up fine. Originally I observed this behaviour on our old-ish NetSUS 2.x system which has been churning away nicely for a few years. With this new problem, I had our server admins upgrade to NetSUS 4.1.0, however the problem persists. I've tried to contact Apple, but nobody at AppleCare seems to even know what NetBoot is. In a similar aside, there appears to be no USB-C Ethernet dongles for Touch Bar MacBook Pros that actually support NetBoot either. I've had to use a similar Frankenstein/piggybacked dongle to NetBoot those models too.

[macmule]

@dj2017 I don't think this is an NetSUS or AutoCasperNBI issue, but more an OS & dongle issue.

NetBoot OS's only load Apple drivers, & if these adaptors need their own or maybe do not support NetBoot then there is little that NetSUS or AutoCasperNBI can do here.

[Lotusshaney]

For netbooting ONLY use Apple Adapters. Use a Thunderbolt 3 to 2 Adapter with a Thunderbolt to Ethernet Adapter. This works 100% of the time as it is all recognised as Apple Hardware with no need for KEXTS or adding the adapters

[dj2017]

I feel like you kind of ignored most of what I said in a rush to close this off. These are USB-C iMacs, with onboard ethernet. What I said is that it only worked with a USB/Ethernet dongle, and refused to work via the onboard ethernet. Are you suggesting 10.12.6 doesn't have the ethernet drivers for the built-in ethernet port on the iMac?

[macmule]

@dj2017 correct i did.

Can you NetBoot with verbose mode enabled & see what shows?

[dj2017]

No, it won't go that far. It won't even spinny globe, let alone get to streaming the NetBoot OS dmg. Option-boot, choose NetBoot volume, black screen, wait (about a minute?), reboot to internal drive. Same NetBoot dmg (kernelcache, booter, etc) boots older iMacs, MacBook Pros from the same NetSUS server. NetBoot from a combination of USB and Ethernet dongles and it works. Same NetSUS server, same (AutoDMG/AutoCasperNBI-created) NetBoot NBI. AutoCasperNBI hasn't been updated since those models (and the MBP Touch Bar) came out - it wouldn't be excluding the drivers for onboard ethernet for those newer models (and the Apple-supplied/recommended Belkin USB-C adapter that's also supported since the first Touch Bar 10.12.# builds)? I know the booter has to be thinned out to fit within... firmware memory limits or something(?) and be under 32k or thereabouts. Based on what you said about drivers, it would sort of make sense, since the Apple USB-Ethernet adapter's been supported in the OS since the original MacBook Air, which would explain why that combination works. So maybe not a NetSUS thing afterall...

[macmule]

@dj2017 there is no forked build so the onboard ethernet should be included within an AutoDMG 10.12.6 OS.dmg & therefore AutoCasperNBI NBI.

Verbose boot should show something, what if you enable it via NVRAM RAM as per:

sudo nvram boot-args="-v"

Then try to NetBoot, this should show something at least.

[dj2017]

I'll give that a try and report back.

[dj2017]

Set boot-args="-v" but got nothing but a black screen until the machine gave up and booted off the internal drive: http://tinypic.com/r/x56qoh/9 I can tftp the footer, and curl the NetBoot.dmg file. Built with AutoCasperNBI 1.3.4, AutoDMG 1.7.3. Same machine successfully booted off the same NetSUS server with the same NBI using what we call the Frankendongle - Targus USB-C to USB-A adapter + Apple USB-A to Ethernet adapter:

[dj2017]

Hi, any further thoughts on this? I can reliably NetBoot older Macs, but not those released since the Touch ID MBP was released. I get no "denied" (crossed out circle) logo, just black screen, then nothing. The only thing I can think of is at this point is to test making an Apple System Image Utility image and see if that works. If not, it must be the OS or hardware; if yes, it's AutoDMG or AutoCasperNBI. Does that logic check out?

[macmule]

@dj2017 No idea. I guess.

But ACNBI uses a similar process to SIU as it's based on the scripts within.

[duncan-mccracken]

@dj2017 Sorry its taken me a little while to get to this, but I wanted to do some serious tests prior to posting...

You're not alone, this has appeared a few times since the release of 10.12, seems to come and go with the 10.12 builds.

I've been able to replicate a very similar issue, when running NetBoot from both macOS Server and NetSUS, so it seems the issue is related the the client OS trying to boot.

Some easy (Terminal) tests to validate this are:

1. Check the route to the server (are there NATs) traceroute
2. Check for HTTP telnet 80
3. Check for TFTP echo "get .nbi/i386/booter" | tftp -e

That should be enough to establish if the connection is getting through

The big one is, that the client can often take a very long time to boot if there are multiple NATs in the trace route, particularly if the Network boundaries have firewalls, as stated before this is not limited to using NetSUS for NetBoot, it also happens from macOS Server.

What happens is the Client OS (which is booting) breaks down the NetBoot.dmg component to very small chunks (64kb) if it detects a NAT (or particularly multiple), the problem gets far worse if the networks are firewalled as it has to re-create the socket for every transaction.

I'm still chasing this down, and its likely that the issue is client side, or network-based, given that it happens regardless of what is providing NetBoot.

I'll everyone posted as I get more information

[macmule]

ahh @mondada have you tried setting the TFTP blocksize to 1460?

I've scoured Slack & @neilmartin83 said he needed to do that.. which sound like a fix for the issue @dj2017 is seeing

[macmule]

on the NetSUS, edit the file /etc/default/tftp-hpa change line 6 to `TFTP_OPTIONS="--secure --blocksize 1460"

might be worth a try?

[dj2017]

$ tftp tftp> connect 10.68.160.90 tftp> get 10.12.6AutoCasperNBI.nbi/i386/booter Received 579092 bytes in 0.6 seconds

$ curl http://10.68.160.90/NetBoot/NetBootSP0/10.12.6AutoCasperNBI.nbi/NetBoot.dmg sp????????????????????????????????????????..[etc]

We have private addressing internally, but although there's some firewalling between the access layer and the data centre, there shouldn't be any NAT. Again, it works for other models sitting right next to the newer iMac that won't play ball - same VLAN, even used the same cable.

I'll try the TFTP modification.

Thanks guys. Really appreciate the input and consideration.

EDIT: just found this based on the blocksize modification. So the suspicion is it's the same/similar thing?

[dj2017]

Awesome. That now works. I can now NetBoot a USB-C iMac successfully. That is a major relief, considering we have rooms and rooms full of iMacs in our labs. The Touch ID MacBook Pro gets further than it did, but seems to balk with: "Error loading kernel cache (0x10)" in verbose mode, which recurs a few times until it gives up and boots off the internal drive. Same OS as the iMac, same OS as it boots off its drive. I'm guessing, then, that this is a USB-C Ethernet adapter/driver issue. Tried ones from Belkin (from Apple), Vrova, Comsol. Same thing. The OS supports these without any installation when booted up normally. https://docs.google.com/spreadsheets/d/18bJlsQlOp0_fGTOY7b2q3F72ha_Nn09GRajGIA9L_Ek/edit#gid=0 Is the NetBoot image and kernel cache affected by what machine it's built on? If I re-AutoCasperNBI the 10.12.6 (16G29) base OS on the MBP Touch ID (with the adapter in), would this change the outcome of the build?

UPDATE: I rebuilt the AutoCasperNBI image using 10.12.6 (16G29) without reducing the size and MBP Touch ID now boots using the Apple/Belkin (white) adapter or a Vrova adapter. This may be a consideration for the reduce feature in AutoCasperNBI.

Is there any downside to the blocksize modification to TFTP? Back specifically to the NetSUS project, is it worth considering setting this by default in NetSUS? Or adding an option in the webadmin, or just exposing to users via the NetSUS documentation?

[dj2017]

Sorry, I realise this is outside the scope of this Issues thread, but how would one set "--blocksize 1460" on macOS Server? Looks like it might need to be an argument in tftp.plist?

[macmule]

@dj2017 sorry for the late reply.

1. no idea where to set the block size on macOS server
2. Interesting datapoint on AutoCasperNBI, what I delete is within: https://github.com/macmule/AutoCasperNBI/blob/119aef36849e8fdddbd04a52a8cb785444bb2eeb/AutoCasperNBI/AutoCasperNBIAppDelegate.applescript#L2352. I don't have a TBP to test. So cannot advise, on a quick glance i'm not deleting anything that should affect NetBoot. But this is why the reduction is an option, just in case.

Are you on the macadmins Slack at all? Might be best to close this off here & pop into the #netboot channel in there.

[macmule]

@dj2017 any change with our 4.2.1 release?

[duncan-mccracken]

Addressed in latest release