[larkost]

Have you tried making an account on the computer after imaging to see if that makes a difference?

[larkost]

I would really recommend that you take the little bit of time to look over InstaUp2Date. It basically does the same thing, but allows for nested lists of updaters, and will even download those updaters from the Apple sites for you.

It is really simple to use. Go and get the latest version from the development site, clear out the InstallerFiles/BaseUpdates and InstallerFiles/CustomPKG folders, and then run the instaUp2Date.py command (it is in AddOns/InstaUp2Date) with “10.6_vanilla” as the argument. It will then go and download the latest list of updates for you, and setup the two folders for you. And it is even easy to create your own catalog files, and have them reference the vanilla ones, so when the vanilla files get updated, yours come along for the ride. And since everyone shares the vanilla catalog files, we all share the same base image. So when something goes wrong you have more eyes looking at it. You can even have InstaUp2Date drive InstaDMG, so it will process multiple images in a row. Here are some sample calls:

[code]/path/to/instaUp2Date/py 10.6_vanilla[/code] download anything that is not cached for a vanilla image, and setup for a InstaDMG run, but will not run it

[code]/path/to/instaUp2Date/py –process 10.6_vanilla[/code] same as above, but then run InstaDMG (note: need to call this with root privileges)

[code]/path/to/instaUp2Date/py –process 10.6_vanilla myImage[/code] same as above, but then will setup and run InstaDMG a second time using the setting from the ‘myImage’ catalog file that you created. This will probably produce 2 images (depending on your settings)

The only thing that it lacks at the moment is the ability to choose BaseOS disks, but that is not actually important at the moment, and I think you might have a large problem that you are missing: if you are installing 10.5.8 then you need to be using chroot jails, but they only work with the 10.5 installer (so you need to be running 10.5 as the host OS), and if you are installing the 10.6.2 update you need to be running the 10.6 installer, and that only works under the 10.6 installer (so you need to be running 10.6 as the host OS). And it is sort of silly to have 10.5.2, 10.5.6, and 10.5.7 base os’s. Just pick one and mix in the latest combo updater and you have something that will work everywhere.

[larkost]

There are a bunch of basic details we need to even begin this:

What version of InstaDMG are you running?
What version of the OS is your host computer running?
Are you using InstaUp2Date to get your vanilla image? This will tell us if you are using an image consistant with others.
When you say you get a ‘dud install’ what do you mean? Does it not boot? Does it boot and the program does not work? What?

And there are some packages that are not going to work with InstaDMG on 10.6 at the moment. I worked really hard to solve the sort of problem that this could be, but in 10.6 this broke. If it is one of the packages that fall in this category, and you are using DeployStudio, then it is possible that adding it as either a post-restore, or first-boot package could get it to work.

[larkost]

I just uploaded a small update to this that fixes a bug reported by James Austin. It only affects things if you are using the -J flag (it was broken), so should not effect most people.

[larkost]

I actually put this bug up on OpenRadar, and it is Radar number 7527256. I would link to it, but these forums tend to think I am spamming when posting urls. I am pretty sure that Apple doesn’t like posting anything about any radars, and that includes OpenRadar. I generally take that into consideration, and post some of the Radars I file because I think that other people might do exactly what you are asking and post duplicates because they care about the issue. I should have posted the chroot one under this rubric, but right now that Radar is in an account I don’t have access to.

To be clear about this: filing duplicate Radars is a really good thing, it tells the people who control what engineers work on what bugs are being run into by people in the real world. Filing duplicates helps them to justify throwing engineer’s time into fixing this thing, rather than fixing that thing. If you care about the issue behind a Radar, by all means file a duplicate bug. If you have other channels to Apple Engineering (like an Apple Support contract, a Support Engineer, or even a good sales rep), then by all means use those as well. Once I get access to my other account I will try and post the Radar number for my chroot bug. The other day I verified that it is still an issue that I can’t work around.

And the workaround should look like:
[code]hdiutil create -srcfolder “/Volumes/Mac OS X Install DVD” -format UDZO -imagekey zlib-level=6 “/Volumes/Destination/Mac OS X Install DVD.dmg”[/code]
… so you are only using one form of escaping (either quoting, or back-slashes, not both).

And I have not seen a hang at this point. Are you sure that it was just not giving feedback?

[larkost]

Other than the redirection of stander err to standard out (2>&1) the caching bit is all covered in the asr man page. Please read that. Then you want to read up on bash output redirection.

I know nothing about needing to run asr across an image a second time. I did read a hint of this over on the DeployStudio site, but suspect that they are being bitten by a problem in hdiutil’s method of creating images with 10.6 that SIU has also been choking on. There is something about the size of the resource forks (due to compressed data in there) that it is choking on in some step. I suspect that this is the real cause of DeployStudio’s woes. Somehow the path that InstaDMG takes has proven to be a both a bit faster than SIU’s, and immune from this particular problem.

[larkost]

I should note that I got an error later on in the processing of the image, it was harmless, but I already filed a radar on it, and am confirming that it was not a fluke (I doubt it was). So you might get errors on the command line, but the image looks good (needs more testing of course…).

Update: I have a solid reproducible bug here, and have given Apple what they need to find it. To avoid it you just need to use quotes around paths rather than escaping spaces. But I still have no reason to believe that this will cause actual problems, only some errors printed to the console.

[larkost]

I an a little confused about what it is you want to do. My guess is that you want to create an image of your installer DVD (the dmg that does into InstallerFiles/BaseOS), and for some reason you want to avoid doing this through Disk Utility.app. Because you are obviously confused about things your first post should have explained what your overall goal was here. By focusing only on what you think is going wrong in the process you have made it much harder to answer your question.

The hdiutil man page should provide you with all the information you need, but you need to read and understand the whole thing first. Assuming that I am guessing what you really want, then a varient like this will do it:
[code]hdiutil create -srcfolder /Volumes/Mac\ OS\ X\ Install\ DVD -format UDZO -imagekey zlib-level=6 “/tmp/Mac OS X Install DVD.dmg”[/code]

But I do thing you are confused about things from there, especially when you are asking about the cached base image. In order for this to be generated successfully you have to go through all of the steps in the script. So if you want a cached base image, just run the script with no extra packages. It will do some extra work at the end, but not all that much really, and it is just computer time.

edit:
Oh… and I would make sure that the output name is “Mac OS X Install DVD.dmg”

[larkost]

I should note that I always had to use this command with 10.5 as well, so I am not sure why it worked for you there. After a couple of conversations I am filing a bug with Apple to ask that they run this command at every boot (effectively): Radar 7525632

http:// openradar.appspot.com/radar?id=137401

[larkost]

It shouldn’t, but I never test MacOS X Server, only client (as both host and target).

Have you made sure that there is no folder already on the image (you can open up the .dmg without hurting anything as it will be read-only)?

[larkost]

There are a few things wrong here:

1) There should be no space after the shebang, so:
[code]#!/bin/bash[/code]

2) ‘sudo’ is not going to help you here. If you check the box to have this be an admin package it will run with admin (root/wheel) rights, and then ‘sudo’ is superfluous. If you don’t check the box then there is no way for it to get the password it needs.

3) When you are writing scripts always use full paths to things. The environment that the script runs in might not have the same path or aliases as your login. This is probably what you are running into since networksetup is in /usr/sbin, and I am not sure that is included in the installer environment path. To find this I used ‘whereis networksetup’.

4) You are putting a password in cleartext. You might not have a choice, but this is a dangerous thing in general, and you should at least cringe at the necessity.

5) I would be careful just calling netoworksetup this way, since it was only in /usr/sbin starting in 10.5. Prior to that it was tucked in the ARD package, and even then you had to know if you were calling the 10.3 or 10.4 version.

6) This is an InstaDMG form, and I am not sure that even the chroot available in 10.5 (for 10.5 images) is going to allow this script to function properly in an InstaDMG workflow. This will definitely fail on 10.6 at the moment.

[larkost]

The SVN command that I am leading you to goes to the latest development version, the HEAD version (that is a SVN/CVS term). At times this can be somewhat dangerous (and I do not guarantee that HEAD will always be workable), but at the moment it should be in good shape.

The changes in HEAD just do exactly what the switch does, but does it automatically for 10.6. I didn’t suggest the switch because I have forgotten where along the way I put it in… I could go back over the SVN history and look, but I am too lazy for that.

[larkost]

You need to be using the latest version from svn. Directions on how to get this are on the Google Code page:

http:// code.google.com/p/instadmg/source/checkout (sorry, can’t make this a url… otherwise the post is rejected as spam)

Once you do that it will automatically disable the chroot when running on top of 10.6 (I have an idea of how I might be able to get around this, but it is going to take a lot of work).

[larkost]

Yes, unfortunately at the moment you have to build 10.6 on 10.6, and 10.5 on 10.5. Yesterday in the shower I had an idea about how to get around this (maybe… it is going to take a little work). But right now that is second or third in line for my attention, and I have been distracted recently. But I do have Macworld coming up in February, and would like to have something to present by that point.

[larkost]

This is just a wild guess, but are you creating the home folder as part of the image creation routine? When you log in the system checks to see if your home folder exists (there is a folder at that path) if so it assumes things are the way you want them to be and does nothing (some things will auto-generate such as the Library/Preferences folders). If you created this folder ahead of time (like to put something on the desktop), then this would be the expected behavior.

Oh… and there is no need to use CarbonCopy Cloner for this, DiskUtility will do the job just fine, and is more predictable about how it works. CCC attempts different things and can fallback to less efficient methods. Most of the time this should not really be an issue, but you don’t need it. I would rather have the warnings in those cases.

[Author]

Posts