NetBoot fails to go diskless for some machines

Sonic84
Contributor III

Hello, I've ben running into a issue when I netboot Macs in my lab. All Macs will netboot successfully (they boot up) but will not be in a diskless state. I can tell by opening disk utility and checking the mount point of Macintosh HD. If it's /Volumes/Macintosh HD the netboot session is diskless. If the mount point is /private/var/netboot, the Mac has not booted in a diskless state and Casper Imaging will crash out when I attempt to image Macintosh HD. This issue is maddening because in a lab of 10 Macs, I can netboot them all and usually 2 of the ten will boot non-diskless. I was wondering if anyone has seen similar issues and has a fix.

All the lab Macs are netbooting off of an Xserve running OS X 10.8.2 server and are using the same netboot NBI. My lab does have one or two gigabit unmanaged switches between the client and the server. I verified that diskless is selected in Server.app. The netboot itself is 10.7.5 loaded with Casper 8.6. Also, older netboots have been giving me the same result.

Any advise would be appreciated. Thank you!

1 ACCEPTED SOLUTION

andyboutte
New Contributor II

I had the same issue with my netboots hosted on a 10.8 server. I followed these steps:

http://www.macos.utah.edu/documentation/administration/setup_netboot_service_on_mac_os_x_10.6.x_client.x_client/setup_netboot_service_on_mac_os_x_10.6.x_client-diskless_netboot.html

and now my 10.5 10.6 10.7 and 10.8 netboots all hosted on 10.8.1 run diskless.

View solution in original post

6 REPLIES 6

andyboutte
New Contributor II

I had the same issue with my netboots hosted on a 10.8 server. I followed these steps:

http://www.macos.utah.edu/documentation/administration/setup_netboot_service_on_mac_os_x_10.6.x_client.x_client/setup_netboot_service_on_mac_os_x_10.6.x_client-diskless_netboot.html

and now my 10.5 10.6 10.7 and 10.8 netboots all hosted on 10.8.1 run diskless.

donmontalvo
Esteemed Contributor II

The "enable" and "diskless" options were disabled by the Server 2.1.0 updater...er...so was DNS. I had to spend some time configuring things again.

Like iOS6 Maps, the Server 2.1.0 update wasn't without issues.

Steve Jobs must be rolling over in his grave.

Don

--
https://donmontalvo.com

rmanly
Contributor III

I did what andy did simply for performance issues and it turned out great.

Creates a local ramdisk and uses that for the shadow file so it isn't hosted on the network and it allows "diskless" operation allowing the internal HD to be unmounted

http://www.macos.utah.edu/documentation/administration/setup_netboot_service_on_mac_os_x_10.6.x_clie...

Sonic84
Contributor III

@andy

your suggestion fixed the issue I'm having. Thank you!

yr_joelbruner
New Contributor III

I had this problem, ended up being I added the NetBootClients0 group to have Read/Write permissions on /Library/Netboot/NetBootClients0 and propagated the ACL permissions. Which is the same effect of setting Everyone to Read/Write UNIX-wise, since the group NetBootClients0 includes Everyone. If you are on 10.6 the NetBootClients0 group doesn't exist so you could just change the Unix permissions, but I believe this is a 10.7/10.8 server issue, so that's kinda moot.

Anyway, that's what it was, the netboot client didn't have permissions to write to the share so if fell back to the local storage. Might have something to do with using HTTP vs. NFS I wonder?

Anyway, that did it. Using the above script will work because you are using RAM as a disk, but it's not solving the underlying problem of permissions, which this seems to be.

yr_joelbruner
New Contributor III

So even though I cleaned up the permissions, it seems the server creates Shadow files with incorrect group permissions that inhibit proper diskless net booting. Only after a couple client reboots are the Shadow file perms corrected (rw-------)

I've filed a bug with Apple, mirrored at Open Radar http://openradar.appspot.com/13937874 If others have this issue, it might be worth it to file bug report (bugreport.apple.com) so this is fixed (maybe in 10.9 but better than never!)