Rather than redo the work on the netboot, I figured I would just use the 10.9.1 build that i used to create the NBI, run the combo update, and re-run it through SIU. That completes as expected, however when I try to netboot a machine I just get a Circle with a line through it.
I can reboot off the (now 10.9.2) partition just fine though, so it seems like it's failing due to the SIU.
Any ideas?
It looks like the 10.9.3 update didn't change anything. The kernelcache file generated by SIU is still too big... 36.7 MBs in my case.
Interesting, I built a new NetBoot image from scratch with the 10.9.3 installer/updater and it boots old and new alike, my 2008 MacPro and my 2013 MacBook Pro just fine.
My NetBoot image was created from a softwareupdated Mac. I was able to boot a MacPro5,1 but a Macmini5,1 failed. The kernelcache file was definitely larger than 32 MBs and since Apple has not updated the firmware on the Macs unable to TFTP files larger than that, it would follow that this is still broken.
FYI: I can confirm that Pepijn and @rmanly's suggestion of replacing the kernelcache with the one created for the NetInstall image worked for me on the two Macs I'm tested with.
Lotusshaney I may have missed it, but where does the script need to be placed ?? What location on the machine I am creating my netboot from.
This thread is very helpful, thank you for everyone that has contributed!
I am ripping my hair out over netboot failing 90% of the time.
Working on these kext issues today and hopefully will have good news to report later!
So far I have been unable to get a working 10.9 nbi. Either my kernelcache is too big (0x7 or 0x17 errors) or it seems the kernelcache boots but then I get a kernel panic. Ugh.
@jrippy You're not using a 2008 iMac to test your 10.9 nbi are you? I found a weird issue where a 2008 iMac with 2GB (2x1GB) of RAM kernel panics right after loading the desktop with a 10.9 netboot session. I can take a stick out, or make it (2x2GB) and it netboots fine. I know there is a rational explanation, but that is what I've discovered through trial and error. 2009 and 2007 iMacs netboot 10.9 fine. If I netboot the 2008 (2x1GB) iMac with 10.8 and image it 10.9 it works fine as well.
@Lotusshaney : awesome script - worked like a champ for me. Thanks!
Thanks for all the posts/ideas here. Unfortunately NetBoot with the JAMF appliance remains a near total fail on my end.
Is there a way to capture log files off a client or the JAMF appliance after a failed NetBoot?
Note: I've already run packet captures in the past to determine why NetBoot across VLANs worked for native Apple NetBoot but not JAMF appliance but did not come up with anything there either.
Assumed the current reason for Netboot failing was due to the kernelcache size issue mentioned above since I was getting the GhostBusters denied symbol on boot. However, after running your resize scripts @Lotusshaney][/url I am just getting an extended NetBoot, then automatic reboot.
Image created via:
Any ideas?
I would try to eliminate variables as potential issues:
The kernel cache issue affects specific machines using a large kernelcache file. NetSUS or Apple Server NetBoot, you'll have the exact same issue. So, if you are able to successfully boot a specific machine with a specific .nbi, that NetBoot Image with that machine is not the problem.
If you're using the LONG bless command to boot across subnets, I believe the share location is a bit different on the NetSUS than on the Apple server (or it was on the versions I used). Given all you've done previously you probably already know that but just wanted to make sure. I think it was the /srv/ I added to the path. Also, I'm using the original NetSUS 1.02 that uses NFS. I haven't gotten the newer ones with HTTP bless command figured out yet.
My bless command looks like this:
/usr/sbin/bless --netboot --booter "tftp://IPAddress/NBIFolder/i386/booter" --kernelcache "tftp://IPAddress/NBIFolder/i386/x86_64/kernelcache" --options "rp=nfs:IPAddress:/srv/NetBoot/NetBootSP0:NBIFolder/NetBoot.DMG" $nextboot
Here's the errors I'm getting around the kernel panics, shown for both 10.8.4 and newer 10.9.3 images:
Anybody seen this "vfs_mountroot () failed" message before? I'm checking file permissions next.
After my last post, I have not yet got NetBoot to work on the latest Server app and a 10.9.3 build.
I noticed the kernelcache was 36MB but after running the script provided above, it is down to 30.1MB with still no ability to netboot.
I did notice that the clients exhibit a completely new characteristic that I've never seen before.
In the past, if there was a problem with a NetBoot client or image, it would attempt to boot it (flashing globe or spinning wheel) and then it would either sit there forever, or just reboot.
With this new 10.9.3 image and latest server version, when I Option-Boot and pick the netboot image, for about 15 seconds, *nothing* happens and the screen appears to be locked up / unresponsive. Then it just boots normally to the local drive.
I dont recall ever seeing this behavior before, is anyone else seeing this?
Also on a sidenote, the server IS generating a shadowfile for the client, about 50MB in size. but I have not yet had a client boot once
Not sure if anyone else is seeing this but in my environment with the NetSUS v3, I had to relocate the NetBoot.dmg file and update the "option root-path" line in my dhcpd.conf before NetBoot would work.
I copied my NetBoot.dmg file out of my NBI folder to /srv/NetBoot/NetBoot.dmg and edited /etc/dhcpd.conf so that the option root-path looked like this:
option root-path "http://netsusIP/NetBoot/NetBoot.dmg";
@wyip that's really odd. Are you saying that the option root-path setting in dhcp.conf was not correct on your instance of the NetSUS? I have about 4 different NetBoot images, so moving the NetBoot.dmg file to the same level as the actual NBI folders would cause some real issues.
FWIW, my option root-path configuration within dhcp.conf appears to show correctly as:
option root-path "http://NetSUSIP/NetBoot/NetBootSP0/NetBootConfigName.nbi/NetBoot.dmg"
I was battling for hours with a clean 10.9.3 server and netboot startup issues with MacBook Pro 2012 and Mac Mini 2009 & 2010. Kept getting "tftpd: read: Connection refused" in the logs. Thought it was something with my network or server but then tried a 10.8.5 Netboot that I had and that worked fine on these computers.
Then I followed Apple and Lotusshaney…..
Took my 10.9.3 netboot drive, re-downloaded 10.9.3 Installer. Applied the 10.9.3 combo updater. Created a NetBoot. Attempted to netboot above Mac Mini. Didn't work. Applied Lotusshaney script. Attempted to netboot same Mac Mini. Worked perfectly. Attempted MacBook Pro and other Mac models…..they all work fine now with this 10.9.3 NetBoot.
Thanks Lotusshaney! Wonderful script and so easy to use!
Can't wait for @bentoms (AKA MacMule) to release this jewel...
https://twitter.com/macmuleblog/status/475424483038474241/photo/1
We're going to drown him in beer at JNUC2014! :D
Don
This may be a dumb question but since I don't use NetBoot very often, is there a need to reconcile the NFS vs HTTP-based NetBoot image configurations?
Specifically, it appears that Apple limited the ability to set the NetBoot images created in System Image Utility in 10.8 and above to HTTP only. As such any images created through SIU are showing up in the configuration files as HTTP in the image's NBI folder -> NBImageInfo.plist. However the bless commands listed above (and the ones I'm using below) are referencing NFS shares within the rp=nfs: section of the command.
Does that work with HTTP-based NetBoot images?
/usr/sbin/bless --verbose --netboot --booter 'tftp://YourServerIP/NB-1093-Casper.nbi/i386/booter' --kernelcache 'tftp://YourServerIP/NB-1093-Casper.nbi/i386/x86_64/kernelcache' --options '**rp=nfs**:YourServerIP:/srv/NetBoot/NetBootSP0:NB-1093-Casper.nbi/NetBoot.dmg' --nextonlyThe NetSUS serves the images via both http and nfs. It advertises the http address but, at least today, it allows either connection. As long as Apple doesn't restrict one method or the other as valid protocols in the firmware of machines, either bless command should work. I am not aware of any hardware that has come out that can't use both protocols.
So, I am getting Netboot 10.9.3 image working on a 2012 Macbook Pro 13", but for a 2013 iMac and a 2011/2012 iMac it just locks up at the Option-Boot screen for about 15 seconds, then boots to the internal drive.
edit: correction it is a 2012 macbook pro 13"
edit2: also a 2009 imac does not even show the 10.9 netboot images as options, maybe because mavericks is deemed not to run on those?
I'm getting "Image Failed" screens when trying to netrestore any 10.9.3 nbi files. 10.9.1 works just fine. Kernalcache file only 15.5MB. NFS and HTTP both fail to restore images via netboot. Last line in installer log says "unable to revert target to bless."
Went back to the drawing board and reviewed Mike Bombich's old NetBoot troubleshooting page:
http://static.afp548.com/mactips/netboot.html
I can confirm that a fresh install of OS X Server (10.9.3) will boot a client, but the exact same freshly-recreate NetBoot image on the NetSUS 3.0.1 running on a fresh VMWare Fusion converted .OVA VM will not.
More specifically, the native NetBoot service (10.102.81.53) responds correctly against a client-side tftp request, while the NetSUS (10.102.81.55) does not (see below):
US-MAC-6147:~ chirtle$ tftp 10.102.81.53
tftp> get NetBoot/NetBootSP0/NB-RestoreDrive-1092.nbi/i386/booter
Received 510024 bytes in 0.5 seconds
tftp> quit
US-MAC-6147:~ chirtle$ tftp 10.102.81.55
tftp> get NetBoot/NetBootSP0/NB-RestoreDrive-1092.nbi/i386/booter
Error code 256: File not foundThe path is different when using the NetSUS versus Apple's NetBoot, both for the dmg when downloading via http or nfs as well as the booter and kernelcache files. I don't have a NetSUS spun up at this very moment, but I believe the tftp command should be:
get NB-RestoreDrive-1092.nbi/i386/booterI'll try in a bit and post back if this is wrong.
Thanks @Josh_S][/url. You have a few bless command examples off the thread below, are those still working examples?
https://jamfnation.jamfsoftware.com/discussion.html?id=4801#responseChild30735
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.