Re: How to restore /var/db/dyld cache?
Re: How to restore /var/db/dyld cache?
- Subject: Re: How to restore /var/db/dyld cache?
- From: Karl Kuehn <email@hidden>
- Date: Wed, 12 Jan 2011 10:41:15 -0800
On Jan 12, 2011, at 10:03 AM, James Bucanek wrote:
>> If you read the man page for update_dyld_shared_cache you will see that you can run it with -root and the supply the path to the mounted volume. I have done this in the past to solve similar issues in a restore situation (there was some funkiness otherwise).
>
> RTFM. Ouch. Yes, you're absolutely correct. I didn't see that option. That might be a workable solution.
>
> I'd still like to know, however, if the cache will automatically rebuild itself or whether it has to be built manually on 10.6.
I believe it should, and it did in *most* of my testing... but I ran into enough funkiness (could be unrelated), that I decided to be conservative and rebuild it. I should note that in InstaDMG, which generates system images, I did not do this and things work fine (a bit longer boot the first time. I had been planning on putting that in, but ran out of time.
So I would do it...
>> If you are worried about the version of update_dyld_shared_cache used,
>> then use the one from the target volume. Unless you have huge deltas in
>> the versions of MacOS X, you should be able to do this.
>
> Big deltas aren't a problem; small ones might be. Big deltas aren't an issue because you *can't* restore one major version of the OS using another. Apple keeps changing the HFS format so things like compressed extended attributes make it impossible to write a bootable OS X 10.6 system using 10.5 (trust me, I've tried).
I do this all the time. But I am always "restoring", not copying. That is, I use the -erase option, so all I am doing is laying down bits, then re-inflating. The only issue I am aware of from 10.5->10.6 is the move of the program code in binaries form the data fork to a compressed stream in the resource fork. But even when copying this should pose no problem, since 10.5 already understands resource forks.
Now there is a secondary issue here, which is the "fragmented catalog" problem, where because of all of the new entries in the Resources catalog it gets too big and asr chokes on it. I know that there are some complexities here that I don't understand. InstaDMG has never choked on this (and everything produced by it always works), whereas System Image Utility seemed to run into the issue headlong. We are doing a couple of things slightly differently, but it never made sense to me why InstaDMG did not encounter the problem.... So your milage may vary there.
--
Karl Kuehn
email@hidden _______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden