@jwilson @pat.best @DaveMB

I have had this issue before - found that the passwords for the Casper Read/Write & Casper Read/Only users were incorrect in the JSS. Therefore, I was unable to mount the share. Once I corrected the passwords in the JSS, all worked fine.

Your logs should also be able to tell you why all the packages are being skipped. Have a look at you imaging logs in the JSS (should show Failed) or the jamf.log file (/var/log folder)

@stevevalle
Yeah, I had that issue when we started with Casper in January on one of my DP's. Everything mounts, but Casper can't seem to erase the drive. If I do it with the disk utility and have Casper do the block copy it works. It's just a lot slower and I have to touch the systems throughout the process, which means the potential for more human mistakes.

What I recall when this was happening was that it appeared that Casper Imaging would unmount the "Macintosh HD" volume when it would start imaging. Then when I noticed it wasn't actually installing the OS, I'd force quit Casper Imaging. Then if you launch terminal and look in /Volumes, "Macintosh HD" wouldn't be there. It would be in Disk Utility and appear to be mounted. When you would try and unmount it in Disk Utility you'd get an error. The only way to unmount it at that point is to do a ```
umount -f /dev/disk0s2
``` then it would appear unmounted in Disk Utility. I'm not sure whats going on here, but it has to have something to do what we're experiencing.

My god I can't believe that I've spaced on posting this. Please try this one simple thing and let me know how it goes.

On a unit experiencing this issue; erase that units autorun data from within the JSS and let me know if that fixes all. I've seen this specific issue before and it can hide through any version of JSS once that file is corrupted.

@Chris_Hafner][/url When can I find and remove that data. Sorry if it something I should know, but kind at a loss right now due to this issue.

Great question. It's changed a bit since version 8.x.x. Here's my best easy answer. Performa a full search so that the computer in question is the only result (I suggest a search based on serial number). Then, DON'T open the computer record. Select the "action" button and then choose "delete autorun data". If you click on the computer record instead it will let you "edit" said data but NOT remove it completely.

Does holding shift when launch Casper Imaging also clear the autorun data?

@DaveMB - I use a shell script to format the drive at the start of the imaging process (set it to run before). This forces the drive to unmount and format. Saves on time too!
diskutil partitionDisk /dev/disk0 1 JHFS+ "Macintosh HD" 100%

@jwilson @Chris_Hafner - Do a search for the computer. Once found, click on it to view its details. An "Autorun Data" & "Delete" button will appear.

@stevevalle Have you ever had an incident where someone accidentally netbooted and had their hard drive wiped with the script? I was considering doing the same thing. I was thinking I'd add a countdown that allow someone to cancel if needed. Thanks.

@ssrussell No, I haven't. I don't set the Auto Image on computers for this reason. I set the Autorun data and just hit return when Casper Imaging is ready to go.

Default delay is 60 seconds Minimum Delay & 60 seconds Maximum Additional Delay. That gives the user 120 seconds to cancel the imaging if they do netboot accidentally. These can be increased.

@stevevalle - have you ever seen this error with your script? I used a similar script in past (and tried yours too), but can't seem to get past it no matter what I do. Frustrating.

Started partitioning on disk0
Unmounting disk
Error: -69888: Couldn't unmount disk

This is using JAMF's NetInstall, wonder if that makes a difference.

@stevevalle - it does seem the Netinstall is the root of my problem. seems like with netboot script works ok but netinstall can't unmount for whatever reason. bummer.

@CasperSally - These are the steps I take to create and deploy a new NetBoot image. Hope this helps!

Setup the Base OS

1.  Startup in recovery mode and Install the OS from Apple
   2.  Once OS is installed, create a new admin user
   3.  Enable the root user
   4.  Logout of the admin user and login as root
   5.  Copy the Casper Suite into the Applications folder
   6.  Open System Preferences
        a. Change the name of the system to NetBoot
        b. Change Energy Saver settings
        c. Turn Screen Saver off
        d. Turn Bluetooth off
        e. Turn Wireless off
        f. Set Automatic Login for root user
        g. Add Casper Imaging to Login Items
        h. Turn off automatic updates in App Store System Preferences
   7.  Open Casper Imaging and add mss details
   8.  Rename Macintosh HD to NetBoot
   9.   Restart the computer to ensure root logs in automatically and Casper imaging opens on startup

Create the NetBoot Image
 
1.  Startup the computer in Target Disk Mode - Ensure that the OS of the Mac is the same as the OS of the NetBoot Image (ie. 10.9 NetBoot Image must be created on a Mac with 10.9 installed)
2.  Create the NetBoot Image with System Image Utility (/System/Library/Core Services)
3. Name of image e.g. Mac OS X 10.9.2 NetBoot
4.  Once completed, copy the new NetBoot folder to the NetBoot Server
     a. Enable new NetBoot Image
          i. Make available over NFS
          ii. Make image available for diskless booting
5. Update kernelcache - if needed for older Macs (https://jamfnation.jamfsoftware.com/discussion.html?id=9779)
6. Reduce size of NetBoot Image to ensure older macs can NetBoot (https://jamfnation.jamfsoftware.com/discussion.html?id=847)
7. Ensure Macs use Diskless (https://jamfnation.jamfsoftware.com/discussion.html?id=5416)

Spectacular instructions. You actually got me to do a double take as this looks eerily close to my own! I've been using this method since the moment I started with the Casper suite and have never looked back.

thanks for the steps @stevevalle. My problem seems to have something to do with using the utah state rc.netboot file, it looks like you're using that too though?

It defaults the RAM disk it uses for booting to rdisk=500k or 256MB of space. When imaging, half the time, that's going down to zero and causing imaging to fail. Usually it stays at 130MB free through the imaging process, but in slower boot environments it's failing half the time.

Even if I bump RAM disk up using @foigus trick here https://jamfnation.jamfsoftware.com/discussion.html?id=7766 to 1GB - I watch the free space go from 800MB to zero in few minutes and can't figure out why. Nothing telling in Activity Monitor. If I go to 2GB, my airs with 2GB of RAM won't boot to it.

I'm following your instructions and will see if I can get diskless working without the utah rc.netboot I guess. In the past, my problem with that was shadow copies on the server were huge and filling up the (too small) SSD too fast.

I was pretty happy when I checked out the Netinstall creator JAMF just released, but we saw kernel panics like crazy with our 2010/2011 macbooks for whatever reason.

If anyone has any clues why my diskless 'untitled' ram disk drops suddenly, I'd love any recommendations.

I'll take a guess it's com.apple.IconServices aggressively caching icons*.

Not related to Casper, I took an AutoDMG dmg and used System Image Utility to create a NetBoot image. AutoDMG created a dmg with very little free space (a couple hundred megabytes). When NetBooting, com.apple.IconServices happily filled that space causing the NetBooted Mac to run out of disk space and hang.

Think of it this way--the NetBoot dmg (i.e. "hard drive") is a trash can, while the shadow file is a trash can liner. Both of them need to be appropriately sized to make NetBoot function:

1) If the trash can (hard drive) only has one gallon of empty space, you can place a 14 gallon trash can liner (shadow) over the can, but you'll only be able able to fit one gallon of content in the trash can before it is full.
2) If the trash can (hard drive) has 14 gallons of empty space, but you place a one gallon trash can liner (shadow) over the can, you'll only be able to fit one gallon of content in the trash can before it is full.

#1 is addressed by having free space on your NetBoot dmg, while #2 is addressed by having a shadow file that's "large enough". AFP shadows should be able to grow as large as the NetBootClients0 AFP share that hosts them will allow, while University of Utah RAM Disk shadow files are capped at the size defined in rc.netboot. Run out of space on the NBI or on the shadow, and the computer will likely hang. Additionally, when using the University of Utah RAM disk tweak, run out of system RAM (i.e. what's left over when the RAM disk is deducted from the physically installed RAM and thus no longer available for OS X to use as traditional RAM) and the Mac will likely grind to a halt.

Balance all three (dmg free space, shadow space available, available RAM) and NetBoot should work. If you don't have enough free space on your NetBoot dmg and you don't want to surrender more of your server's disk space, you can:

#Convert the disk image to sparse image format (UDSP)

hdiutil convert -format UDSP -o /Library/NetBoot0/NetBoot /Library/NetBoot0/NetBoot.dmg



#Resize the sparse image to 15 GB

hdiutil resize -size 15g /Library/NetBoot0/NetBoot.sparseimage



#Move the previous NetBoot dmg to the trash

mv /Library/NetBoot0/NetBoot.dmg ~/.Trash

#(or alternately just delete it)

#rm /Library/NetBoot0/NetBoot.dmg



#Rename the sparse image back to ".dmg"

mv /Library/NetBoot0/NetBoot.sparseimage /Library/NetBoot0/NetBoot.dmg

Using a sparse image allows you to declare an arbitrary dmg size without actually using up that space until the dmg actually needs it. Note 15GB is a number I pulled out of a hat--more elegant code would use the existing size and append an additional X GB of space.

You may also be interested in using @bentoms Casper NetBoot Creator, when released.

*com.apple.IconServices is disk space-hungry--start at the first mention of "Open Files" here:
http://blog.magnusviri.com/what-is-var-folders.html

@stevevalle][/url

5. Update kernelcache - if needed for older Macs
(https://jamfnation.jamfsoftware.com/discussion.html?id=9779)

Reasonably sure that 10.9.4+ no longer needs this per a tweet from Pepijn Bruienne (which I can't seem to find) and this JAMF Nation post:
https://jamfnation.jamfsoftware.com/discussion.html?id=9836#responseChild63325

6. Reduce size of NetBoot Image to ensure older macs can NetBoot (https://jamfnation.jamfsoftware.com/discussion.html?id=847)

Reducing disk usage by deleting things shouldn't affect whether or not a computer can boot from a NetBoot dmg as long as there is sufficient free space on the dmg (see discussion in previous post).

Kernel Cache reduction is not needed when creating NetBoot images on 10.9.4 as the Imagetool & it's GUI System Image Utility now handle it.

Sadly I was am still being hit by this, so will delay the beta of AutoCasperNBI.

@foigus. I missed some of your post when testing earlier... & just for an email about my NetBoot server running out of space. So that's fun. We've also had some major power issues that have impacted our environment.

I was all about to blame the rc.netboot file when I realised I was also not resizing the dmg.

I'll amend AutoCasperNBI to always add + 2GB, will recheck my server space & will try again Monday.

If that works, then I'll have a beta out next week.

Those you that are affecting by this issue, can you restart the mac?

Mine were not restarting, I'd quit Casper Imaging & run:

sudo shutdown -r now

Then I'd get an error about a resource not being able to be unmounted as it was in use.

This resource seems to be the rc.netboot created RAM disk. Which would kindof make sense if the NetBoot.dmg was not resized.

@foigus - as always - thanks so much. Your explanation was great. I did the steps you outlined and am testing now.

I started with rdisk at 256MB, during imaging I was showing ~130MB free.
I bumped rdisk to 1G, immediately upon opening terminal to run 'diskutil -info untitled', it's showing only 315MB free.

I'm watching some test images now, one of the larger non compressed images is down to 240MB with plenty of packages left... worried I might still run out of spaces on the non compiled configs.

I am not wrapping my brain around why increasing the rdisk size didn't make more free space available on the RAM disk. I used rc.netboot in the past and didn't compile all of my images and never had issues with casper imaging quitting/RAM running out of space.

@bentoms - which issue are you talking about? I'm testing the utah rc.netboot and am able to reboot ok. Would like to help if I could.

I am not wrapping my brain around why increasing the rdisk size didn't make more free space available on the RAM disk.

@CasperSally][/url][/url][/url --I know you tweeted earlier you were having success, but I'll answer the question.

Continuing the trash can analogy here:

https://jamfnation.jamfsoftware.com/discussion.html?id=11084#responseChild63722

Increasing the value of the "rdisk" variable (the size the RAM Disk-based shadow file in a University of Utah rc.netboot file) is like using a bigger trash can liner. When OS X NetBoots, it will read the free space that's baked into the NetBoot dmg (i.e. the trash can). Even if the shadow file is 2GB, if the NetBoot dmg declares it has 200MB of free space that's what OS X is going to see and believe, thus the trash can is teensy while the trash can liner is (relatively) huge. The trash can will fill up even though the liner will be able to accept more stuff.

If you're going to use the University of Utah modified rc.netboot file:

- Ensure your NetBoot dmg has sufficient free space available (I'd personally suggest at least 2GB)
- Ensure you have sufficient RAM remaining on the computer after deducting the RAM being used for the RAM disk shadow file. For example, if you try to NetBoot a Mac with 2GB of RAM and use a 2GB RAM disk shadow file, you're gonna have a bad time
- While NetBooted, do not write a quantity of data to the NetBooted "hard drive" that exceeds the size of your shadow file

@bentoms
I am having this issue with a 10.6.8 NBI using the modified rc.netboot file. If I restore an image using Casper Imaging 9.32, no, I can not reboot. It just hangs on the blue screen for days. If I boot to the NBI and restore an image with Disk Utility or ASR, it reboots fine. If I revert the rc.netboot file, Casper can reboot my 10.6 machines again, but I am limited to imaging ~10 at a time before I start to get the same issue as the OP.

I have not experienced this issue on 10.9.2+. With or without using rc.netboot to make a ramdisk, Casper can image the machine and reboot it fine. Just like with 10.6, I have the same issue as the OP after booting ~10 systems if I do not use the RAM disk.

I get the same results when booting from a 10.6, 10.7, 10.8 or 10.9 server. At this point it is easier to manually reboot machines after imaging them then to be limited to ~10 at a time, but I would love to find a proper solution.

Strange that so many people are having this problem on 10.9. Does anybody else still maintain a 10.6 NBI these days?

Can't wait to try AutoCasperNBI! Will it support 10.6.8? I still have to image thousands of older machines each year...

Going back to the original question. Seeing this now.

Checked In JSS in Casper Imaging failed log for the MBA. First error of note:

Error: The file MBA_Image_1.dmg could not be opened. Please verify the permissions.

Anyone else seeing this tweeker?