IMac Pro debuts custom Apple T2 chip to handle secure boot, password. Has anyone been able to netboot an iMac Pro? Or reImage one? Aug 15, 2018 - With NetBoot not being available for the iMac Pro but still available for other models, it wasn't yet clear if NetBoot-based workflows for setting up.
Hi, I've spend the last 2 days trying to get NetBoot working and I'm pulling my hair out right now. Situation: Mac Mini, OS X El Capitan with Server configured. Created a BootImage based on El Capitan with AutoCasperNBI, everything is set up using info from various sources. Trying to perform a NetBoot from a MacBook Pro (mid 2015) with a network connection that is in the same VLAN as the Mac Mini results in a black screen and a reboot to it's internal SSD after a timeout. I used crsutil in the recovery partition to 'whitelist' the server (which apparently has to be done with the introduction of El Cap).
I see in the system.log on the server lots of NetBoot: 1,68:5b:35:ca:29:9f BSDP ACKLIST sent 10.90.78.4 pktsize 343 logs. So my MacBook gets an IP adres, asks the Server for a boot image but never moves to the BSDP ACKSELECT phase, where it selects my default image and proceeds with the boot.
I've checked the folder permissions on the NetBootSP0 folder and those seem to be fine (Everyone has read rights). I also created a default image with the System Image Utility, to see if that could be the issue: doesn't make a difference. Stopped and started the NetBoot service, rebuild the folder structure, nothing.
Already checked a lot of suggestions floating around here and @ Google but not success so far. Does anyone have an idea what could be the issue? Thanks in advance!
I have netboot sorta working on 2 minis running 10.10.5 and server.app 5.0.15. Netboot OS is 10.11.3, as we have new devices arriving shortly. The booting is incredibly slow, using AutoDMG w/ AutoCasperNBI, and also old school w/ SIU, neither any better. SO slow and uneven that with a prestage I almost have to wait for the first to get all the way to the desktop before starting the next to assure they go in order! The diskless piece is horrible.
I can netboot 5 computers, and of those 5, 2 or 3 will not get a shadow file on the server, which then causes it to be created on the local HD, so Casper Imaging cannot erase. Once that happens, the drive is a total bitch to get wiped as it will not unmount.
This is happening intermittently on BOTH servers. (Yes, and for staff I do not nuke and pave, but for student devices, I do) I have dumped everything and set back up from scratch, with no improvement. Also, the 'load balancing' which used to nicely alternate automatically between two netboot servers with same image ID is pitiful. I have a call today with Apple. My plan B is to boot to a USB drive and then image from the network. When I do that, I get past the OS block copy, installs one package, the rest are set to install at reboot. It copies 2 or three packages, and then the screen goes black, the IP address vanishes and everything fails.
Screen lock is OFF, screensaver is OFF, Sleep is set to 3 hours. Delete the record, reuse the prestage, reboot the target with the same USB, works perfectly. Allright, checked the setup @ my home. Worked flawlessly via NFS, so the culprit is the network @ work somehow.
Checked with a colleague yesterday to see if he knew a solution but he didn't unfortunately. I guess that I have to ask our network admins nicely for help. Bottomline - Client gets IP address in the 'holding ALT to select boot device' stage according to our Windows DC DHCP servers (are you supposed to be able to ping the client during that stage btw?) - there is traffic between the Client and the Mac Mini - Mac Mini presents a list of bootable Images to the Client, but the Client does nothing with that information thus generating an endless list of BSDP ACKLIST entries in the system.log on the server. We use System Image Utility to Create our Netboot set and bless it now, use Composer to create our Base Images, and have an Xserve racked in our Data Center as our Netboot server. We had to add the IP of the netboot server to the IP helper tables of the VLANs to get it to see when holding Option/Alt the NBI option, and to prevent timeout issues for booting. We also have to have them connected via ethernet, as Networking has a fit if we try to do anything over wireless. Before we added the IP to the helper tables it would stall and then give us a black screen.
Sometimes restarting the netboot server would fix it, but the thing that fixed it permanently (so far) for us was adding it to the IP Helper table and making sure it was racked in the data center. When it was on the same VLAN or even tried to traverse before racking it didn't work consistently. I just wanted to chime in here since we are getting similar behavior with our 10.11.4 NetRestore images. We have had a mac mini on 10.10.3 for some time now that serves all of our netboot/netrestore images. We recently built a new imaging lab for a new location and i setup a fresh mac mini with 10.11.4, latest server, and created a new 10.11.4 netrestore NBI via SIU. The results we see when booting this image is extremely sporadic.you might get a machine that will quickly complete the net restore process, but you might only get 1/2 to 3/4 through the boot progress bar and it will just hang. I just took the 10.10.3 netboot image that we run from our old imaging lab and confirmed that machines are able to netbook this image from the new mac mini server in a timely manner, but not the 10.11.4 netrestore images.any thoughts on why 10.11.4 restores would be so inconsistent?
Now I'm going to try moving the 10.10.3 netboot server up to our new imaging lab and see if it can handle serving out the 10.11.4 net restore image any better than the fresh 10.11.4 server.Update and our 10.11.4 net restore image seems to complete in a decent amount of time when served from our new location with the mini thats running Yosemite.something is up with 10.11.4 server and net restore from what we are seeing. My next plan of action is to take the new mac mini that has an SSD and 10.11.4, bring it back down to 10.10.X, and just not look at 10.11.4 for our netboot server yet. Thanks for the response at least we aren't alone.
Are you using an actual netboot image, netrestore or netinstall? Our netboot image is 10.10. Does anyone have any idea why we would also be seeing inconsistent hostnames in the netinstall connection list? We are seeing sporadic results with some being fully qualified and others not MacBook-Pro-2.local MacBook-Air.local MacBook-Pro-3.kibsd.org The machines are obviously not bound to the domain as they are just in the boot process, but if one machine shows a fully qualified name, I kinda expect them all to reflect that.inconsistencies.