[Tim Sutton]

Posted to instadmg-dev since posting rarely works for me here anymore. Creating a brand new account didn’t help either.

There’s a couple very important points regarding my patcher, so it would be best to read the thread before trying to apply it.

[Tim Sutton]

[QUOTE][u]Quote by: Allister[/u][p]Melmaninga wrote to me asking to post the following:

With the older versions (1.5 I think) I used InstaUp2date in
conjunction with DeployStudio. Basically I used symlinks for the
InstaUp2DatePackages and the OutputFiles folders that pointed
respectively to the Packages and Masters/HFS folders in my
DeployStudio Repository. This meant the exact same packages and
images were used in both tools.
[/p][/QUOTE]

FWIW, Karl mentioned in his macsysadmin talk this past October that he does this for the OutputFiles destination for instadmg, when he wants to output straight to DS.

[Tim Sutton]

[QUOTE][u]Quote by: tristan_mason[/u][p][QUOTE][u] I imported the grey install disc (build 10J3210), .[/p][/QUOTE]

Really? I thought that was a no no??? I thought we were restricted to “vanilla” OS discs or is that just “best practice”?

Tris[/p][/QUOTE]

it’s best practice to use retail discs when possible. But this is really only an issue when you’re deploying that image to several different models of hardware. Since this build is only intended for a specific machine type there’s no harm.

As Allister said, some very large deployments actually find it best to maintain many system-specific images in an automated fashion as opposed to counting on apple having universal hardware support in the retail build stream.

[Tim Sutton]

Ok, I found the culprit for iPhoto ’11. UpdateSplash and UpdateSplashOnline get set, setting the same real value of 9.1000003814697266. In fact, the info splash is suppressed if I remove UpdateSplash, leaving only UpdateSplashOnline.

dontShowWhatsNew seems to have changed from a bool to a string (it setting ‘NO’) if it doesn’t exist, doesn’t seem to change anything regardless. FirstLaunch doesn’t seem to control anything to do with the behaviour I’m trying to suppress.

I’ve whittled it down to the following to suppress pop-ups and dialogs:

[code]

AskHotPlugAction

GeocodeLookupPreference
2
UpdateSplashOnline
9.1000003814697266
[/code]

[Tim Sutton]

Yes, when I first started using instaUp2Date I would get that error frequently. I don’t recall there being a definitive conclusion as to why it happens for people, though I’ve heard of reboots fixing it. It could also be that there are still processes running from a previous build if it was ever aborted — if I ever abort a previous run, I ctrl-C a few times, and check that the various disk image-related processes and python are no longer running.

[Tim Sutton]

If you ran importDisk.py on the MBP grey disc, it should spit out a file like “MacOS X Client 10.6.6 10G3210.dmg” in InstallerFiles/InstallerDiscs. (I don’t remember if that’s the correct build no. for the 17″ MBP I did last week)

instaUp2Date will check the catalog you’re building (and its includes) for the “Installer Disc Builds:” settings line, which should contain the same build no. of the install disc you want to use. If, for example, you want to build your 10.6_vanilla image with this specific build, modify the catalog or create a new one, to include only the build no. you want. I don’t know how instaUp2Date prioritizes build no.’s if it finds multiple candidates for a catalog in InstallerDiscs.

[Tim Sutton]

But therein lies the facility of instadmg to minimize the overhead of maintaining different images. Just build your instaUp2Date catalog off the mbp grey disc instead of the retail generic build, and you have an identical image save for the driver differences between the retail and hardware-specific builds.

[Tim Sutton]

[QUOTE][u]Quote by: dead2sin[/u][p]Yes. I created one for use as a NetBoot set and it works perfectly fine for imaging purposes (DeployStudio Netboot set).

Nate[/p][/QUOTE]

Ditto. Created a Netboot set today and it works fine with NB110314.

For instaUp2Date, I had an existing catalog I wanted to build for a 17″ Thunderbolt MBP. I imported the grey install disc (build 10J3210), made a copy of my 10.6_vanilla catalog and put only that build number (also removing unnecessary Apple updates), made a copy of my main build catalog to include the modified 10.6_vanilla instead, and had a perfectly working image with all my other applications.

[Tim Sutton]

[QUOTE][u]Quote by: Goldberg[/u][p]Cygnus2112, are using InstaUp2Date or just InstaDMG? I tested andyboutte’s directions including his full distribution file with InstaDMG (I’m not using InstaUp2Date) and it doesn’t work for me yet. I understand and follow the directions but I keep getting the iLife.pkg file on the root of the drive. Hmm…[/p][/QUOTE]

I am using instaUp2Date. AFAIK instaUp2Date will install the first package it finds at the root of the .dmg. I only briefly used instaDMG before I switched to up2Date, so I can’t think off-hand what could be causing the issue in your case – if you can properly install your dist-edited .pkg via the command-line, something weird is going on with instaDMG.

Of course, instaUp2Date is just queuing up instaDMG in the background anyway, it just has more sophisticated logic (among many other things!) for building its work queue.

[Tim Sutton]

Hi all,

Just wanted to confirm that following andyboutte’s directions on editing the distribution file worked.

If I would just change the alias to a symlink, it would work via the Finder but not via installer at the command-line.. to echo others’ experience.

Thanks!

[Tim Sutton]

Wow! Wish I’d known that months ago. Another good excuse to dig through the codebase more often. Guess I’ll refactor my custom iLife and Office catalogs…

[Tim Sutton]

That’s precisely the method I’ve been using for a custom Office and iLife install: wrap the mpkg with InstallerChoices.xml in a dmg. My lab image uses both of these along with a slimmed OS 10.6 install.

I’d have to double-check, but I’m fairly certain I’m running on the latest svn, at least with Karl’s last commits.

Have you tried skipping the .dmg and just leaving the xml in the same folder as the package? That should also work.

[Tim Sutton]

This idea works fine. I use it to install our site-provisioned Sophos or other small packages that are picky and cause problems when repacked.

In your firstboot, run:

installer -pkg /path/to/your/pkg/file -target /

[Tim Sutton]

It’s possible to easily script it as part of your firstboot. I copy a certificate to /usr/local/share as part of my general support package (which is common across all images), and somewhere in my common firstboot I have this:

/usr/bin/security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /usr/local/share/the_certificate.cer

I’m also fairly clueless about certificates, but this has been what’s worked for me. I suppose it would be possible to have a postflight script that would run this command with the keychain path prepended with $3 so that it will point to the target volume in the InstaDMG build. Never tried that however.

[Author]

Posts