[larkost]

The CS Suite does not use .pkg for the install method, so it will not fit directly into an InstaDMG workflow. You can repackage the results of the installer, but then you are going to run into all of the nasty details about the CS Suite. Here are a few hints of what I found doing this:
[list]
[*] You need to be using a volume license, anything requiring activation is not going to be pleasant
[*] You can’t do piecemeal installs. So you can’t have one thing that installs Photoshop, and then add another that adds InDesign. You have to instal everything you want in one shot. Adobe has a couple of databases that get overwritten in bad ways if you do anything else. If you need different layout, then you need to have multiple packages that have everything that that install type needs.
[*] You are going to have to play around a bit. It is probably not going to work the first time.
[/list]
If you get a chance, talk to Adobe about these problems.

[larkost]

If you read my reply a little more closely you will notice that you need 3 updaters, not the 1 you had: 7.1, 7.1.4, and 7.1.5.

[larkost]

My guess on the first item would be that the iPhoto 7.1.5 Update lists iPhoto 7.1.4 update as a requirement, which in turn requires at least the iPhoto 7.1 update (which requires only the stock iPhoto 7). The way InstaDMG works we bypass much of that system, so you can break things this way if you are not paying attention.

“iMovie (previous version).localized” usually comes from iMovie ’06. I always have that on my systems, so have never tried things without it. It is possible that the installer script is picking up that you have iMovie ’06 on your booted system and so is creating the folder. That is purely a guess, and I would have to do a lot of looking into things to check on that though (I have plans for something that would eliminate this possibility, but no time to work on it).

[larkost]

First off, you are using a slightly different version of InstaUp2Date than I have on my computer because the line numbers don’t match. But I am always using the latest development version (since I am the developer).

I think I have an idea of what is going on. For some reason it is unable to open a temporary file in /tmp. To prove this you could change (around line 775):
[code]OUTPUTFILE = os.fdopen(fileDescriptor, “w+b”)
if OUTPUTFILE == None:
raise Exception(); # TODO: better errors[/code]
to:
[code]OUTPUTFILE = os.fdopen(fileDescriptor, “w+b”)
if OUTPUTFILE == None:
print(‘Yep, this is the problem’)
raise Exception(); # TODO: better errors[/code]

Then when you run the code, if I am right, then you will get the message ‘Yep, this is the problem’.

[larkost]

I am not sure I completely understand the direction of your question, so I am going to try two approaches to answering it:

1) With InstaUp2Date you can feel free to store both the .pkg containing dmg’s and the catalog files on a http server, you just have to make sure that all the references in your catalog files are of the http variety. InstaUp2Date will pull all of the packages down locally into the caches as I was not sure how much I wanted to trust the network connection with such a big burst of information. This is one of the decisions that I am going to review for the next round. I think that the checksum issues can be dealt with. But I deliberately made sure that catalog files could be used remotely with the idea in mind that there could be central places to get the vanilla catalog.

2) The output of InstaDMG is ready for ASR restore, and that takes about 14 minutes with my base image on an iMac (7 to restore, 7 to verify). Anything that involved also putting custom packages on afterwards really belongs in a deployment system, and InstaDMG is not one of those. It only produces a “base” image. We do take the idea of what can go into a “base” image a bit farther than most, but it sounds to me like you would be well off to pair InstaDMG with something along the line of [url=http://www.apple-scripts.com/?q=node/5]PKGImage[/url] (note: this is not a endorsement, I have never used the product) as your deployment tool.

[larkost]

Welcome to the fold!

First off I will mention that you might want to look at my InstaUp2Date (included in the InstaDMG distribution), and especially at the vanilla.catalog file. With it and a 10.5 DVD image you can pretty quickly have a vanilla image that has most of the latest updates (I am a little behind right now). It will still boot to the first-run path (video with sound, first time registration , etc), but now will be very close to being up-to-date.

Now on to some direct answers:

1) At this point there is little to no differences on what is installed by the installers based on what hardware it is running on, especially if you are using “Retail” disks like you are (which is highly, highly encouraged). There are a couple of clinkers: if you don’t have a DVD drive the DVD player won’t be installed, and some of the newer MacBooks/MacBook Pros have videos showing how to use the finger swipes that are not included in either the retail disks or the updates. So the install that we capture in InstaDMG will run virtually everywhere (that that version of the OS supports).

MacOS X itself takes care of loading the appropriate drivers at boot time. It then caches this for faster subsequent boots. But there is no driver nightmare like there is on the Windows side: every MacOS X install supports all of the hardware that that version supports. This is why you can make external FireWire drives that will boot all of Apple’s current hardware (there is a minor trick to this, more on that later), or move a hard drive from one computer to another.

That being said, that there are certain things that get made specific upon the first boot, but this is less machine-specific and more randomly generated IDs. If you then copy a computer after first boot these can come along for the ride and get in the way in odd corners. InstaDMG avoids these nicely.

2) I would run the InstaDMG process on you latest computer for 2 reasons: The first is that newer computers have faster and larger disks than old computers and InstaDMG is hungry for both disk speed and space. The second is that later computers have newer hardware, the specific example of this would be a DVD drive. If the installers don’t detect that then they don’t install the DVD Player. The is a binary decision, and it does not matter what DVD drive you have. Who knows how this might change if Blueray ever gets included in Macs….

And the bit of code that you found is due to a peculiarity in the Installer DVD code that apple has written. If it is running on Intel hardware then it will only install to a GPT format drive and if it is PPC it will only install to Apple Partition Map drives. This does protect PPC hardware that can only boot APM, but it is a bit odd for Intel hardware since it will boot from partitions on either format (or even Microsoft’s MBR format).

This leads me to the note from above: if you want to create a FireWire drive that will boot both PPC and Intel hardware then the format needs to be APM (PPC limitation). If you have a PPC machine handy you can make this easily and it will just naturally boot Intel computers (assuming the version of the OS supports that hardware). If you want to create the drive from an Intel computer then you are left with two options:

– Hack up the installer to bypass this little bit of code. I have seen this done and it works fine from that point on

– Install the OS to a GPT formated drive, then copy (block mode) the volume to your FireWire drive.

InstaDMG of course can help you in this by creating a block-copy-ready image that you could then push down. Just to emphasize this: the only difference between the two installs is the disk formats, the volumes on those disks are identical.

[larkost]

My understanding is that SIU has been using this technique all along in the NetInstal form, so that probably means that it will go back to the installer (the executable) on 10.5.0. And this should not care about what sort of packages you feed it. In theory you could use this to modify a 10.4 install that is done while running on 10.5 (note: I have never tried that install).

So my initial testing seems to indicate that this is a direct replacement for the format you feed into the -applyChoiceChangesXML option. This is totally undocumented, and I would never have known to look without a hint from “a little birdie”.

[larkost]

Greg has also posted his Macworld slides, along with those from the rest of the presenters (at least those of us who provided them):

http://www.macenterprise.org/macworld-2008-slides/imaging-track

[larkost]

I think that are going to have to treat this upgrade like all the others: we will have to wait until the next point release and trust that that will roll in support for the single giant button that is going to revolutionize the way we all compute. Long live the one giant button!

PS… Anyone want to donate a MacBook Wheel to the development team? I can’t wait to start developing using the touch wheel!

[larkost]

Are you sure you have the right UUID applied to the file, and have you checked to make sure that it is being put in the right place on the target system in (/private)/var/db/dslocal/nodes/Default/users? And have you checked permissions (root-only)?

[larkost]

I was the one who put that bit of code into place, and the thinking was to make sure that the sort order was completely predictable. I also wanted to make sure that odd things such as .DS_Store and ._ files did not make it in. Given those goals, enforcing the documented names seemed like a reasonable measure. And since I was working on InstaUp2Date at the time, i just lined up the names the one produced to exactly the names that the other allowed, and vise-versa.

We could probably relax this to allow a numeric component and then a text component, but to me this points out exactly one of the places where I thought the InstaDMG set-of-folders approach was a less-than-optimal design. This is one of the reasons I created InstaUp2Date: you can have full names attached to all the items and they have no bearing on the order they get run. It looks like the two codebases will get merged at some point in the future.. so eventually the whole conversation will go away.

And I don’t think that spaces in the names is going to matter at all. I was pretty anal about making sure that things are escaped where ever possible. And I think that needing to start things out with 0’s is already confusing enough to people. Making them understand that ‘a’ comes after both ‘A’ and ‘Z’ (because of case-sensitive sort order) is not really going to work in most cases.

[larkost]

No need to pre-mount. If you place a dmg of the second disk in the folder with the appropriately named first one, it will be mounted. None of the fancy mounting that other dmg’s get treated with, but it will still be mounted. Somewhere out there I would like to also appropriately unmount it, but that would require a language change (probably), as the looping we do gets a bit silly in bash.

[larkost]

This is a perennial problem, and InstaDMG unfortunately in not able to get around it. I have repeatedly requested that builds like this have a pkg in them that would be the difference between the last build and the new one, but that is not how they are structured.

So you are left with two choices:

1) hack the installer that comes with the new hardware slightly and then use the new installer disk as your base disk (watch out for bundled software that you might not have licenses for on everything else)

The major problem with this route is that the new build is not guaranteed to work on any other hardware than what is shipped with. Most of the time it does, but the gotchas can be hard to catch, and really bad.

2) make a separate build for the new hardware until the next update comes along and fixes this for you.

[larkost]

I don’t think that that is going to do what you want it to. While you are running the kickstart from the new volume, it is still probably going to alter files on your host OS. You are going to need to track down the files that kickstart alters, and then alter those.

[larkost]

I would guess it would work the same way it does on 32bit Intel machines: it just does not give you the option to go use Java 6 or the 64bit versions of Java 5. I have been testing this with a build done on a Mac Pro, and tests done on a Core Duo iMac (not a Core 2 Duo). Things have gone well so far.

[Author]

Posts