Imaging issue

[jwilson]

I am having an issue when imaging..

First the details : Casper 9.32
Macbook Airs
Os : 10.9.3

Issue : When imaging, I have a constant issue of the image skipping all package and going to the naming of the machine part, and staying stuck on it. Has anyone else had this issue, and if so any possible fixes for it.

[CasperSally]

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.

[foigus]

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

[foigus]

@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).

[bentoms]

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.

[bentoms]

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.

[bentoms]

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.

[CasperSally]

@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.

[foigus]

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

[activitymonitor]

@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...

[jbutler47]

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?