problem (again) booting from underlying volume after Sandbox updated
 

Well, it happened again! (See this post for original issue).

Once again, my Mac Pro won't boot from the main hard drive but WILL boot from the Sandbox created from that drive. Same symptom: I hear the chimes, the gray screen appears, the gear spins for about 2 seconds, and the machine shuts down.

Here's what I noticed....after restoring from a month old SD! backup and reapplying changes to the main drive I made in the last month, I again created a Sandbox. I booted off of the Sandbox. A few days later I applied the Combo Updater to update the Sandbox from 10.5.2 to 10.5.4 and then rebooted off of the Sandbox and all seemed good.

Then, a few days after that I wanted to boot off of the underlying main drive, and wham, the Mac Pro shut down, just as it did weeks earlier!

So, it seems there is some evil interaction going on.

Fortunately, I have a relatively recent SD! clone that I made right after getting my HD back to speed (a good caution, I guess!).

I'm going to conduct a test....after creating a new Sandbox, I will (a) make sure I can boot both from the Sandbox and the main drive, (b) apply the 10.5.4 update to the Sandbox, and see if I can boot from the main drive. I will not use the machine for anything else as I conduct this test, so we can be (relatively) certain that it's the step of applying the OS update that is the culprit (if the symptom occurs again!).

I'll report back shortly, I hope.

You should send me a "system.log" from the drive that shuts down -- send it to the support address. It might indicate *why* it's shutting down.

A (possibly) dumb question....how do I send you a system.log from a drive I can't boot off of? In the past, the way I've gotten logs is via Console, but not from a different drive. Is there a place I can find the system.log of the offending drive while booted from a different drive (obviously, I can't boot from a drive that won't boot!).

Well, that test crapped out! Right after applying the 10.5.4 combo update, I was able to boot up both off of the Sandbox and the main drive. Darn! So much for that theory!

I WAS able to locate the system.log file. I think what I need to do at this point is to work off of the Sandbox, as I prefer to, and periodically try to boot off of the main drive. The next time it won't boot, I'll send you the system.log file.

Now, what I've been doing to recover from this mess is that when I couldn't boot off of the main drive but COULD off of the Sandbox, I've copied my Desktop and Documents folder to some free space somewhere, cloned back using SD! from a working, booting backup, and copying back the desktop and documents. That's really tedious, because it takes about 45 minutes each way to copy the docs and desktop (mostly the docs). Is there a better way?

Thanks, as always, for your help.

If you're cloning back, I don't quite see why you're copying off Desktop/Documents, because they never 'move' -- they're on the original drive anyway. And you should always be doing a regular backup of the base drive.

As far as getting the system.log from the base drive when you're on the sandbox, you'd use Finder's "Go To Folder" command to open

/Volumes/the-base-drive-name/private/var/log

system.log is in there.

Well, I may be missing something, but here's why..

I have a complete SD! clone that's, say, a week old. In the last week, I've altered documents. Since the Sandbox boots, and the main drive doesn't, I want to restore my system on the main drive back to health. If I just clone back my week-old SD! backup, I lose any document file changes in the last week. So, what I've been doing is:

1. copy off the documents from the Sandbox/main drive shared Documents folder
2. Clone back to the main drive from the week old backup
3. copy back the documents from step 1

Am I missing something obvious?

Wouldn't you just Smart Update the Sandbox back to the original drive?

Yes, I could certainly do that. That's what I did when I first ran into this problem, and the result was not good. But, the cause of that "not goodness" could, of course, been due to something else.

That's what I'm thinking. This is a pretty common way to handle the Sandbox. But if you're having these kinds of problems on a regular basis (it's working fine here), there might be something you're running that's causing the issue and is incompatible with Sandboxing.

So you're saying that it's pretty common for folks (despite the warning in the docs!) to Smart Copy back from the Sandbox to the underlying drive? That's certainly an easier way to handle updating that drive rather than manually reapplying the changes.....But if I take that approach, I'd better always first boot off of the underlying drive to make sure that works!

(You can give me .625 kudos for not reflexively saying "it must be SD! that's causing my difficulties, since the symptom is showing up when I use the Sandbox)

The warning is basically to be careful: if you don't use the right options, and don't back up the base volume first (if you make a mistake), you could lose data. But Sandbox users are typically pretty sophisticated.

If you Smart Update the base drive from the Sandbox (using "Backup - all files", not the Sandbox scripts, as you know), the OS would be updated to the one from the Sandbox, so bootability on the base drive is more a function of the Sandbox itself...