troubleshooting a difference between: install, image, restore v InstDMG deploy (Snow Leopard)

[alantrewartha]

I have had a very easy time so far making a Snow Leopard image build with InstaDMG and deployment via DeployStudio (yes all built in SL too). But I’ve suddenly hit a very specific but dealbreaking snag.

When I try to install Extensis Universal Type Client 2.1 – the most recent version specifically built for snow leopard – i get a dud install on a mac imaged from the instadmg-rolled DMG.

BUT if i do a vanilla install of SL on a client and use DStudio to make an image and restore that image to a mac, installing UTC2.1 works fine.

For ages I thought this was a problem with UTC2.1 – no other applications were giving me problems – but then the fresh install from the DVD worked ok.

Then I stripped back the InstaDMG build chain to JUST the base OS dvd DMG (made from the same installer DVD) and the two small createuser and clearreg PKGs, and that gives me a non-working app.

To summarise: I have 2 systems – one from a vanilla install from the SL DVD (then made into an ASR image and re-restored to another mac), and another made by making a DMG of the same DVD, running it through InstaDMG with a an absolute basic build chain and restoring the result to a disk by ASR.

Somehow installing UTC2.1 mpkg installer gives me different results on the two resulting systems. On the InstaDMG route UTC shows “Font unobtainable” in the previews and you can’t activate it (but you can ‘collect’ the font to the desktop and pop that file in ~/Library/Fonts!)

So first off, what I am asking very generically is, has anyone got any tips on how to troubleshoot where the difference may lie?

Second, more specifically but less likely, if anyone else is working on the same sort of build: SL + InstaDMG + UTC2.1, do you have the same issue, or, more hopefully, have you had no problem at all, and I’m the big doofus somewhere in all this.

[this is a bit tl;dr, but thanks for any help given]

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

[alantrewartha]

sorry for posting this long cry for help and then vanishing off the internets. DOUBLE apology for the n00b mistake of not posting ANY system/version details. and finally sorry if i didn’t make it clear that by ‘dud install’ i was specifically talking about the install of UTC. Pretty much everything else *seems* ok.

the build system, the DeployStudio, everything running is 10.6.2
InstaDMG is 1.5 (svn revision: 222)

i’m not using InstaUp2Date. to work out the source of the problem I’ve stripped back to (pretty much) JUST the install DVD image (10.6) to work out at what point UTC is going wrong. The only packages in the chain are clearReg.pkg and createUser.pkg.

i’m not putting UTC in the build chain either – that’s a manual install post-boot.

but what i can get are 2 systems, one made by InstaDMG, one make by a manual install (then imaged, then restored). the distinguishing feature between them is that when I install UTC2 it’s not working on one (InstaDMG) but is fine on the other.

hope that’s clarified some.

[larkost]

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

[alantrewartha]

i tried making an ADDITIONAL admin account and installing from that – as it seemed to be something that needed ruling out.

I’m going back to scratch now – remaking a DMG of the DVD, the checksum matched the first one in instaDMG so it went with the cache, and now i’m running again with the cache folder empty.

i’ll try deploying without createUser in the build and not disabling the apple setup stuff…

[alantrewartha]

ok, that’s pretty much everything that can be stripped back now, but no change…

method A
create
– standard install from SL DVD
– don’t run setup, quit and netboot
– create image with DStudio.
deploy
– restore image with Dstudio to fresh HD
– reboot new machine
– run through apple setup (inc make main admin user)
– install UTC2.1 – all is well

method B
create
– make DMG from same SL DVD
– run DVD image through InstaDMG (as above) with NO supplementary PKGs
– copy output DMG to DStudio repository
deploy
– restore image with Dstudio to fresh HD
– reboot new machine
– run through apple setup (inc make main admin user)
– install UTC2.1 – “font unavailable’ across the board

so now i have to trace the differences in the two DMGs. there is the obvious difference of in size, which (when the DMGs are mounted) amounts to: method A 4.93GB, method B 5.57GB (in the “Used” section of Get Info)

will let you know what I find. But if anyone has any advice how to track down differences, that would be lovely.

[alantrewartha]

using just ‘du’ on the two images the first difference I’ve found is that the InstaDMG image has

ls -lh /private/var/db/dyld
-rw-r–r– 1 pubsys staff 190M 27 Jan 17:50 dyld_shared_cache_i386
-rw-r–r– 1 pubsys staff 48K 27 Jan 17:50 dyld_shared_cache_i386.map
-rw-r–r– 1 pubsys staff 188M 27 Jan 17:50 dyld_shared_cache_x86_64
-rw-r–r– 1 pubsys staff 47K 27 Jan 17:50 dyld_shared_cache_x86_64.map
drwxr-xr-x 8 pubsys staff 272B 14 Jul 2009 shared_region_roots

where the other image has
-rw-r–r– 1 root wheel 48K 27 Jan 14:47 dyld_shared_cache_i386.map
-rw-r–r– 1 root wheel 47K 27 Jan 14:48 dyld_shared_cache_x86_64.map
drwxr-xr-x 8 root wheel 272B 14 Jul 2009 shared_region_roots

and the db folder (above it) has a few more items in it. I *think* i read that DStudio’s image process deliberately clears those dyld_shared_cache_ files.

i read https://www.afp548.com/forum/viewtopic.php?showtopic=25426 too on the subject which didn’t seem too concerned.

I tried a safe boot (which i think deletes/rebuilds those files) and that didn’t help either.

[dead2sin]

I forgot to post on that older thread, but there was a pretty simple fix for the issue. It turned out to be a permissions issue.

I edited the instadmg.bash file in order to fix the issue.

In the clean_up_image function, I added the following line:

[code] #Fix Permissions
/usr/sbin/diskutil repairPermissions “$TARGET_IMAGE_MOUNT”[/code]

I added this after “Close any open files on the target” but before “Delete extensions.mkext”

It has resolved all dyld issues I had been having.

Hope that helps!

Nate

[alantrewartha]

THANK YOU SO VERY MUCH

that did the trick 😀 😀 😀 😀

i feel only SLIGHTLY foolish as the problem did feel like a classic permissions issue with the app.

just for the record i did a simple ‘repair permissions’ with Disk Utility and that made UTC2.1 behave itself. so i’m sure that extra line in the build process will also get things on their feet again

I will now go back to my full SL instaDMG with all the PKGs and that extra line in the script [edit update: it worked btw]

I OWE YOU!

love this forum, love instadmg.

[jdyck]

Funny enough I was struggling with a completely different problem that adding the Permissions Repair step has also fixed…

In my case, using InstaDMG to build a Snow Leopard image with iWork 09 was resulting in an image with a bug – the iWork applications would crush together the larger fonts (such as in the Newsletter templates). After quite a bit of playing around trying to narrow down what was causing the problem, this has fixed it.

Perhaps we should get the Permissions repair step built into InstaDMG so we don’t have to keep adding with with successive updates?

[Per Olofsson]

I was just about to add this to my own copy of instadmg.bash, but svn update came with this lovely little present:

[code]added repair permissions to instadmg, added a tool to import installer DVDs and
a new location for them (instadmg does not know about this yet), changed the
checksum code completely – compatible for single files but incompatible for
folders[/code]
Time to build a new image with iTunes 9.0.3…

[Author]

Posts