@clifhirtle
Those ones should still work. I believe for 10.9 that you cannot omit the kernelcache file for the NetInstall anymore.
I had one of my student employees troubleshooting this some more, and he was able to replace the tftp binary on my Mac Mini Server with a linux-compiled TFTP-HPA, which apparently allows for more customization including changing the block size. This appeared to fix the issue with the kernel cache not transferring. however, the clients are still not netbooting due to other issues which we're currently looking into
Thanks for confirming @Josh_S. Problem appears related to the NFS mount, perhaps specifically the syntax of the bless command across subnets.
Using a local subnet VM and/or native Apple NetBoot server I can boot the clients off the exact same NetBoot images by selection within startup disk, option on boot, or basic "bless -server bsdp://ServerIP" command, but get stuck with same vfs_mountroot failed errors I pasted above when using the extended command, whether on local subnet or across subnets.
Server-side I’m showing the following error within a /var/log/syslog tail:
jssadmin@NetSUS:~$ tail /var/log/syslog
Jun 16 12:25:17 NetSUS dhcpd: All rights reserved.
Jun 16 12:25:17 NetSUS dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jun 16 12:25:17 NetSUS dhcpd: Wrote 0 class decls to leases file.
Jun 16 12:25:17 NetSUS dhcpd: Wrote 0 leases to leases file.
Jun 16 12:25:17 NetSUS dhcpd: Listening on LPF/eth0/00:50:56
79:0e/10.110.200.0/24
Jun 16 12:25:17 NetSUS dhcpd: Sending on LPF/eth0/00:50:56
79:0e/10.110.200.0/24
Jun 16 12:25:17 NetSUS dhcpd: Sending on Socket/fallback/fallback-net
Jun 16 12:26:30 NetSUS in.tftpdp19424]: tftp: client does not accept options
Jun 16 12:26:31 NetSUS in.tftpdp19430]: tftp: client does not accept options
Jun 16 12:27:30 NetSUS mountdt1167]: authenticated mount request from 10.102.81.52:1022 for /srv/NetBoot/NetBootSP0 (/srv/NetBoot/NetBootSP0)
Here's the specific bless command I'm using now to boot to the NetSUS, which matches all examples posted:
escript]bless --verbose --netboot --booter tftp://NetSUSIP/NB-RestoreDrive-1092.nbi/i386/booter --kernelcache tftp://NetSUSIP/NB-RestoreDrive-1092.nbi/i386/x86_64/kernelcache --options 'rp=nfs:NetSUSIP:/srv/NetBoot/NetBootSP0:NB-RestoreDrive-1092.nbi/NetBoot.dmg' --nextonly
[/script]
More testing with wireshark reveals a possible path error with tftp (?) on a 2013 iMac
Wireshark says TFTP is trying to pull this file:
/private/tftpboot/NetBoot/NetBootSP0/Netboot10.9.3.nbi/i386//private/tftpboot/NetBoot/NetBootSP0/Netboot10.9.3.nbi/i386/x86_64/kernelcache
Which appears to obviously be the wrong path.
My student worker was able to get it to work by running bless commands manually, which we have never had to do with Apple's netboot
To make iMacs boot,
sudo bless --verbose --booter
tftp://10.5.128.117//private/tftpboot/NetBoot/NetBootSP0/Netboot10.9.3.nbi/i386/booter
--kernelcache
tftp://10.5.128.117//private/tftpboot/NetBoot/NetBootSP0/Netboot10.9.3.nbi/i386/x86_64/kernelcache
--options
'rp=ncs:10.5.128.117:/Library/NetBoot/NetBootSP0:Netboot10.9.3.nbi/NetBoot.dmg'
--nextonly
Anyone know what's going on here? Is it System Image Utility the root of the problems (buggy/broken)? Or the TFTP version Apple is using in the firmware?
Had a 10.9.3 netboot image that was working for all newer hardware, but some 2010 macbooks were unable to boot to it and eventually booting to internal drive (though some same age 2010 macbooks were getting to netboot fine?).
Tried script in this thread and got immediate panic error mentioning 'unable to find driver for this platform "ACPI...."
Back to the drawing board.
Interestingly, I now have NetInstall image working via the same syntax as above, but am still failing out on NetBoot image at the very point where the authenticated mount is listed in the NetSUS' syslog.
Also, I created a new NetBoot image off a machine's existing machine's drive, kernelcache size 36.7MB, and ends up with the GhostBusters symbol on boot. Checking NetSUS syslog shows the following. If I am reading this right, NetSUS is refusing the TFTP request (?). Is there a specific reason the NetSUS would be denying a client's TFTP request? The NBI's NBImageInfo.plist file does show this specific model in its "DisabledSystemIdentifiers" array, but I've seen that across nearly every image I've created as well.
Jun 18 11:19:00 NetSUS dhcpd: DHCPACK to 10.110.200.241 (00:50:56:a0:00:83) via eth0
Jun 18 11:19:21 NetSUS in.tftpd[29869]: tftpd: read(ack): Connection refused
Lastly, FWIW some similar errors reported by a few others and possible link back to sparseimage creation of NetBoot images in thread below:
https://jamfnation.jamfsoftware.com/discussion.html?id=5252
@clifhirtle HAHA. Ghostbusters symbol. awesome.

After scanning more packets than Kevin Mitnick on a double-shot high at Starbucks, I gave up, double-checked with our network folks, and discovered the CO to add the IP helper on our local switch never... quite... made... it... through (though marked as such) 6 mo back. Never been so relieved to hear something did not happen, as I was seriously thinking I was going crazy with all the testing in a back room test lab with no windows and bad A/C in June.
15m + a download of JNIC 4.0 (https://jamfnation.jamfsoftware.com/viewProduct.html?id=13&view=info) and I am up and running with a network Casper Imaging workflow off the universal restore drive I already had booting (10.9.2 + 10.9.3 combo update).
Thanks for all the ideas/support from folks here. Much appreciated.
Made a new 10.9.4 NetBoot image using System Image Utility on 10.9.4 on Friday and the kernalcache file was 16MB. That should at least simplify things for machines whose firmware still only allows 32MB max TFTP downlad size
I had a working NetBoot image with newer models but when I tried it on a 13-inch MacBook Pro (Mid 2012) I got the prohibitory sign. When checking the kernalcache it was >36MB. I decided to try out the recently updated https://jamfnation.jamfsoftware.com/viewProduct.html?id=13&view=info and now have a working NetBoot image with a kernalcache only 13.5MB in size.
Thank you for the long awaited update, JAMF!
Just wanted to re-confirm that after we modified the tftp client on the server, all further netbooting has been successful.
@jlogsdon, thanks for posting that link! I had no idea JAMF updated it. I'll have to try it out soon
Same as @dlondon.
Created a OS X 10.9.4 NetBoot image by installing 10.9.4 Combo on top of factory OS and captured using 10.9.4 System Image Utility. The kernelcache file is 16.6 MB.
Thanks
@Kumarasinghe,
That's great news! I haven't had a chance to test out the new Image Utility, but it looks promising.
Hopefully this will save me from having to maintain a custom modified version of TFTP on my Mac Mini hosting the Netboot...
Yep 10.9.4 SIU solves it.
I also employed the reduction method is you're running on 10.9.x - 10.9.3 in AutoCasperNBI. https://jamfnation.jamfsoftware.com/discussion.html?id=11356
So is it confirmed that System Image Utility in 10.9.4 + Combo Update fixes it?
I've tried running the SIU in 10.9.4 but netrestore fails before I get to the installation progress.
I'm not sure about NetRestore, was thinking NetBoot.
Should be the same concept no?
Right I get that it's for pre-built images but I'm getting a similar error to the above.
I'll just test it out and see if the combo update helps...
@DLiang is this a NetSUS btw?
@bentoms][/url it has reposado on it, why? It it bad to use a SUS server with netrestore?
Forgot to mention that the combo update did not make any difference in the netrestore process.
FYI for anyone having issues with Sierra netboots on older hardware: https://openradar.appspot.com/28432978
anyone else having a Déjà-vu here?
@m.entholzner Oh yep.. i spoke to @frank about this on Slack:
Yea. I put a fix in (AutoCasperNBI) for when the issue happened in 10.9, never removed it & lucked out.
Hi,
I'm seeing the same problem again with an image created with SIU of a 10.12.1 machine.
In verbose NetBoot mode I see "Error loading kernel cache (0x7)" see attached
and the size of the kernelcache file is 68M
A new machine netboots fine but my trusty old test workhorse now gives the above error and fails
Regards,
David