Home › Forums › Software › InstaDMG › dyld shared cache issues on 10.6 Builds

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • October 6, 2009 at 7:19 pm #377293
    dead2sin
    Participant

    I’ve noticed on my Snow Leopard images that I’m getting the following errors in the system log:

    [code]Oct 6 10:04:57 localhost com.apple.kextd[10]: Cache file /System/Library/Caches/com.apple.kext.caches/Directories//System/Library/Extensions/KextIdentifiers.plist.gz is out of date; not using.
    Oct 6 10:04:50 localhost com.apple.launchd[1]: *** launchd[1] has started up. ***
    Oct 6 10:04:57 localhost com.apple.kextd[10]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:04:57 localhost com.apple.notifyd[11]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:04:57 localhost com.apple.syslogd[12]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:01 localhost com.apple.diskarbitrationd[13]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:01 localhost com.apple.configd[14]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.bsd.dirhelper[38]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.hidd[30]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.dynamic_pager[33]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.SystemStarter[19]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.scsid[24]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.bootlog[39]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.vsdbutil[17]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.statd.notify[21]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.firmwaresyncd[32]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.configureLocalKDC[37]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.KernelEventAgent[28]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.loginwindow[27]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.securityd[23]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:02 localhost com.apple.DirectoryServices[35]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.autofsd[40]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.aslmanager[41]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.DumpPanic[34]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.metadata.mds[25]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.systemkeychain[20]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.liberty.firstboot[43]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost bootlog[39]: BOOT_TIME: 1254848690 0
    Oct 6 10:05:03 localhost com.apple.CoreRAID[36]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.distnoted[45]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost DeployStudio Post-Restoration script[44]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.smb.sharepoints[22]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.UpdateSettings[18]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.fseventsd[31]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.IFCStart[29]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:03 localhost com.apple.autofsd[40]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:04 localhost fseventsd[31]: could not open <> (No such file or directory)
    Oct 6 10:05:04 localhost com.apple.warmd[16]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache
    Oct 6 10:05:05 localhost com.apple.vsdbutil[17]: dyld: shared cached file was build against a different libSystem.dylib, ignoring cache[/code]

    This is a first boot on a brand new 10.6 image. It happens on a base image as well as one that is more “built up” package wise. After googling a while, I found the following article:

    [url]http://developer.apple.com/mac/library/releasenotes/DeveloperTools/RN-dyld/index.html[/url]

    It appears that 10.5 would run the command listed if it looked like the cache was wrong, but 10.6 no longer does that. It seems that this command might need to be added to a first boot script in order to fix the cache issue on the image.

    Anyone else run into this yet?

    Nate

    October 6, 2009 at 10:04 pm #377294
    blake
    Participant

    Yep we saw this issue. I have added the following command to our firstboot.sh script. I tested it with 10.5 and running it doesn’t hurt anything.
    [code]sudo update_dyld_shared_cache[/code]

    November 9, 2009 at 7:41 pm #377478
    walt
    Participant

    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

    November 9, 2009 at 8:00 pm #377481
    dead2sin
    Participant

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

    November 9, 2009 at 9:59 pm #377484
    walt
    Participant

    You’re right, I didn’t read the man page closely enough. [url]http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man1/update_dyld_shared_cache.1.html[/url]

    According to the man page the -root switch will work but you have to run the command from the volume you want to update the cache on so it matches.

    [i]-root directory
    This option specifies the root of an OS installation for which dyld’s shared cache should
    be updated. This is used by the Installer to update the dyld shared cache in a partition
    other than the one you into which you are currently booted. The cache files are created in
    the var/db/dyld directory of the specified directory. [b]Note: if you are manually doing
    this, be sure to run the update_dyld_shared_cache tool that is in the partition being
    updated. This assures the cache format created will match that expected when booting off
    that partition.[/b][/i]

    Also I noticed this in the man page as well:
    [i]-universal_boot
    This option can only be used running on an machine with an Intel processor. It builds
    caches that can be used when booting on both 32-bit and 64-bit machines.[/i]

    It makes sense to to build the cache for 64 and 32 bit machines so I added that switch as well.

    So the correct code for the postflight script would be:
    [code]

    # Set variable to location of update_dyld_shared_cache command on target volume.
    UPDATE_DYLD=”$3/usr/bin/update_dyld_shared_cache”

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

    # Direct command to target volume.
    $UPDATE_DYLD -universal_boot -root $ROOT
    [/code]

    That should do it.

    November 10, 2009 at 1:08 pm #377488
    dead2sin
    Participant

    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

    November 11, 2009 at 3:23 pm #377508
    dead2sin
    Participant

    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.

    January 29, 2010 at 3:23 pm #377895
    dead2sin
    Participant

    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.

    February 17, 2010 at 9:24 pm #378009
    knowmad
    Participant

    any chance one of these fixes has made it into an ‘official’ version of the script?

  • Author
    Posts
Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.

Comments are closed

Copyright © 2025 AFP548. All Rights Reserved.