[foilpan]

check the version of your mounted installer dmg like so: defaults read /Volumes//System/Library/CoreServices/SystemVersion ProductBuildVersion

add the version to the list of allowed installers if it’s newer.

if you really want to use the 10.7.3 combo (you may not need it), change the checksum in the vanilla catalog until it’s updated in svn. run checksum.py on the combo update download to generate the hash.

[foilpan]

have you tried prefixing some of your commands with $3 in the path? that will ensure the changes are made to the target path and not the booted volume.

here’s an explanation of some of the default variables the installer will handle: [url]http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html[/url]

also, it may be better to deal with these prefs with mcx.

[foilpan]

from reading the DS forum posts and [url]https://derflounder.wordpress.com/2011/08/04/creating-a-never-booted-10-7-image-with-included-recovery-hd-partition[/url], it looks like DS lays own a standard recovery partition, not one you have to create yourself.

try it and update your findings here. my opinion is that if my deployment tools handle this, i don’t want to spend any time making it work in other ways.

[foilpan]

i don’t think this functionality should be incorporated in instadmg.

the recovery partition is relatively static, so what’s the benefit of using instadmg to produce one rather than relying on your deployment tool of choice (deploystudio, casper, etc.) to do so?

[foilpan]

also try booting in single user mode to check logs on a machine that loops like that. there’s most likely detail in the logs that will help you.

i use instadmg produced images in a similar fashion sometimes and have never had an issue.

[foilpan]

check like so. composer may show you this in the editing pane somewhere, but i forget where.

defaults read /path/to/app.pkg/Contents/Info CFBundleIdentifier

[foilpan]

i second using munki for this.

my usual approach is to build the base image (os + local admin account + munki) and install apps and whatever else on first boot via munki or other methods.

it’s not worth building in huge app suites for me, since my clients’ needs will be different. the modular approach is way more flexible.

[foilpan]

try removing or commenting out the “Installer Disc Builds” line and running it again. i’ve built a few images using the new build discs that ship with these laptops, and they’ve worked fine for me.

[foilpan]

same here. i imaged via casper netboot, and both the new mbp and an older white macbook booted and ran just fine with it.

[foilpan]

right. it’s both interactive and unnecessary in this case.

[foilpan]

you might also try adding a “networksetup -detectnewhardware” and a short sleep interval before attempting to set the name.

[foilpan]

you don’t need to preface the commands with sudo if you require admin authentication to install the package. the postflight will effectively run as root.

[foilpan]

have you tried using munki for app updates and deployment?

it would save you a ton of time, since you already have all your pkgs ready.

look into that before slogging through any manual work.

also, when you say the image didn’t work, what do you mean by that? does the restore fail at some point? does a pkg install barf somewhere in the process? does the image restore to disk, but the machine is unbootable? just trying to get an idea of what you’re experiencing.

for reference, i generally try to keep base images really small. a 10.6.6 image created the other day with instadmg is ~4.5 GB. it contains all apple updates, munki and config, a firstboot script to get things going, a hidden local admin, puppet, and git. then on first boot, munki launches to install any additional pkgs required and reboots again, if needed.

remember that since you have all the modular pieces, you can be pretty flexible in how you deploy the payload. it doesn’t all have to be baked into the deployment image, especially if you’re only working with 10/100 switching.

[foilpan]

do they work if you wrap them in a dmg? worth a shot…

[foilpan]

you could probably wrap up the installers in one .mpkg instead. i’m not sure why apple doesn’t do that in the first place.

[Author]

Posts