[dead2sin]

I am going to be updating our images in the next week, so I’ll be giving 1.6b2 a workout 🙂 I’ll report back how it goes for me. I’ve been having issues with some installers, so I have high hopes that the new chroot method you are using will allow them to install.

Thanks again for all your work!

Nate

[dead2sin]

[QUOTE][u]Quote by: larkost[/u][p]The closest thing to an archive at the moment is on the MacEnterprise site:

http://www.macenterprise.org/macworld-2010-slides

I am trying to encourage other presenters to put their slides up, but you get what you get.[/p][/QUOTE]

Awesome, thanks for the link. I looked on their website and didn’t see an obvious place where they would keep the slides. Your presentation looked good as well. I think its clear just by looking at the options that InstaDMG is the only way to go. I tried one other product and I didn’t like it very much at all. Sure, it was a graphical interface, but it was really slow.

Thanks for all the work you’ve done and will continue to do on InstaDMG, it has been a real life saver!

[dead2sin]

[QUOTE][u]Quote by: larkost[/u][p]Thank you to everyone who responded, the presentation went really well (a bit long…) and the slide turned out really well. If anyone wants to see the slides my co-presenter has posted them at this link:

http://clc.its.psu.edu/Labs/Mac/Resources/Presentations/MW2010-IT871.zip

I did remove the “who’s using” slide form this version of the slides (among other changes) as I hadn’t asked for explicit permission to have it anywhere other then on-screen for the conference. I don’t think I am going to go back and review that decision, but at some point we should have a place where companies can put their names as users.[/p][/QUOTE]

Thanks for the link to the presentation. Do you know if there is a page that has all the presentations for download?

[dead2sin]

This has actually been resolved. I fixed it by adding a line to the instadmg.bash file as follows:

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.

[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

[dead2sin]

You can get all the options for the installer (the exact names) by using the installer command.

It should be something like:

installer -showChoicesXML -pkg /path/to/osinstall/pkg.pkg

I forget the name of the actual package, but it is buried within the OS install DVD.

My current installerchoices.xml looks like this:

[code]
Popular_PrinterDrivers
Host_PrinterDrivers
LanguageTranslations
[/code]

For the stuff you are wanting, it should look something like this:

[code]
All_PrinterDrivers
LanguageTranslations
AdditionalFonts
Rosetta
[/code]

According to the options that the command I mentioned spits out, X11 is installed by default as well as QuickTime Player 7 (Somehow I don’t remember this being default when I installed from CD). As a result, you don’t need those in the installerchoices file.

I think that covers it. Let me know if it fixes any of the issues for you.

[dead2sin]

I figured it wasn’t a HUGE issue, but I get really annoyed when there are errors in system.log that shouldn’t really be there. They make it harder to track down other issues and indicate that *something* isn’t working as intended. Either way, I’m just OCD about errors, so I am glad to have them gone.

[dead2sin]

[QUOTE][u]Quote by: akinspe[/u][p]I had a similar problem. I added a /usr/sbin/diskutil repairPermissions “$TARGET_IMAGE_MOUNT” to the build train and it fixed those fontd issues. My rough estimation was that it had to do with the permissions of the /Library and specifically /Library/Caches
[/p][/QUOTE]

You sir are my new hero. Thank you VERY much! I couldn’t find a thing using google, but this has solved the problem.

Nate

[dead2sin]

I had the same issue. I upgraded the system that was running InstaDMG to 10.6.2 and it seemed to resolve the issue.

I STILL have a weird issue where fontd isn’t working, but it now installs 10.6.2.

[dead2sin]

10.6.2 did not fix the issue. Still getting the errors above when building images.

[dead2sin]

Its funny, because I used the exact same script you used and it seemed to fix it for me. This way you just found does indeed look better though, so I will update my script as well.

thanks again,

Nate

[dead2sin]

10.6.2 just came out and it mentions some font fixes. Perhaps it was really an issue with 10.6.1. I’ll update this thread if 10.6.2 fixes the issue.

[dead2sin]

This is pretty urgent issue as far as Snow Leopard InstaDMG builds go. The dyld issue is fixed (thanks walt!), but the fontd issue remains. It prevents Photoshop from using any of the fonts it installs.

This is the error that keeps repeating:

[code]Nov 9 14:07:52 netboot003 /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Support/fontd[251]: ATS is unable to switch to Read/Write database – ATS will run off of a read-only database. Only System Fonts will be available.[/code]

Anyone else run into this error in their system log? I’ve tried using the atsutil to remove the database and generate a new one, but it still gives that error. I don’t get this error whilst using a fresh install off of DVD, as I mentioned before.

Any suggestions are welcome!

[dead2sin]

[QUOTE][u]Quote by: walt[/u][p]Thanks for the tip. I was able to get this to work by putting this command in a postflight script and bake it into the image workflow, which is a little nicer than throwing it into a first boot script (I know I’ve got too many already).

# Set variable to target volume we are installing the package to.
ROOT=”$3/”

# Direct command to target volume.
update_dyld_shared_cache -root $ROOT[/p][/QUOTE]

I’ll have to give that a shot. Question is, doesn’t that just build the cache based upon the machine you are building the image with? Or how does that work?

On all my cloned images in the past, I’ve simply deleted /var/db/dyld and it would regenerated it on first boot instead of throwing errors about one already existing.

[dead2sin]

[QUOTE][u]Quote by: walt[/u][p]See this thread to resolve the dyld shared cache issue.

[url]https://www.afp548.com/forum/viewtopic.php?showtopic=25426[/url]

Hopefully that fixes your problem.[/p][/QUOTE]

I’ve been doing that on my images, but it doesn’t fix this issue. I’m going to look at the instadmg.bash script and see about adding some lines in the cleanup that delete the dyld cache. Perhaps that will fix it.

[Author]

Posts