I know, I know: it's not a real Mac. But still: the boot volume should be separate from all the under-the-hood tricks that get it working.

So why after a volume restore, does an attempt to boot the system result in the "No mach_kernel" message?

Procedure: re-create the volume with a fresh install of OS X. Install QRecall. Run it and restore the existing volume from the backup.

Since that didn't work, I'm currently restoring my user folder and will work on reinstalling apps manually. The restore, from a 2TB hard drive to a 512GB SSD, seems to be taking a very long time (4 hours, 51 minutes and counting). After the initial progress bar finished (about 40 minutes ago), it changed to a barber pole and it still going. Now, it might be that's just a result of the restore process having to re-assemble files from pieces. But as long as I'm here, a couple of questions:

1. My backup currently has 57 layers. Is that an unusually high number? Should I merge more often?
2. What's going on when the barber pole is animating?
3. Any ideas on why a whole-volume restore didn't work?

Thanks...

David Ramsey wrote:1. My backup currently has 57 layers. Is that an unusually high number? Should I merge more often?

The number of layers will have some impact on performance, but doesn't fundamentally change how files are restored. As far as QRecall is concerned, there's no difference between 2 layers and 200 layers. And for the record, I have archives with over 500 layers that restore just fine.

2. What's going on when the barber pole is animating?

There's a quirk that affects very large restore actions. There's a separate process that estimates the amount of data that's going to be restored. It takes awhile to generate that estimate, which is why you initially see the barber poll. The estimate process, however, can underestimate the amount of data to restore. Once the restore has restored the amount of data in the estimate, it switches back to the barber poll because at this point it doesn't know how much data remains to restore.

3. Any ideas on why a whole-volume restore didn't work?

I don't know. In theory, you shouldn't have any problem restoring a bootable OS X volume. Here's some things to look out for:

The "Show Deleted Items" view option was not turned on.

After formatting the new drive, and before restoring, make sure the "Ignore ownership and permission" option was not checked.

I assume that both the capture and restore were authorized to use administrative privileges.

I assume you restored the volume by holding down the option key and choosing Archive > Restore Volume To... (or by dragging the archive volume icon, dropping it into the restore volume, and choosing the "Replace Volume" option when the dialog popped up).

Did you try blessing the volume after restoring it?

James Bucanek wrote:

3. Any ideas on why a whole-volume restore didn't work?

I don't know. In theory, you shouldn't have any problem restoring a bootable OS X volume. Here's some things to look out for:

The "Show Deleted Items" view option was not turned on.

Hm. It was turned on. Why should that make a difference?

After formatting the new drive, and before restoring, make sure the "Ignore ownership and permission" option was not checked.

Checked where?

I assume that both the capture and restore were authorized to use administrative privileges.

Yes.

I assume you restored the volume by holding down the option key and choosing Archive > Restore Volume To... (or by dragging the archive volume icon, dropping it into the restore volume, and choosing the "Replace Volume" option when the dialog popped up).

No; I backed out to the first level of the archive, right-clicked on the volume, and selected "Restore". Is that valid?

Did you try blessing the volume after restoring it?

Shades of System 9! Not even sure how I'd do this on OS X...but no. I didn't have any way of mounting the volume.

I should emphasize that I was restoring to the volume I booted from, which I assume is OK.

David Ramsey wrote:

James Bucanek wrote:

The "Show Deleted Items" view option was not turned on.

Hm. It was turned on. Why should that make a difference?

When you enable "Show Deleted Items" it changes the way folders/volumes are restored. The restore action restores not only the captured items, but all previously deleted items still in the archive. This can pollute the OS with tens of thousands of previously deleted files, which often make the resulting system unusable.

This was probably the issue, and also why the restore took so long. In the next version of QRecall, you'll receive a stern warning if you attempt to do this.

After formatting the new drive, and before restoring, make sure the "Ignore ownership and permission" option was not checked.

Checked where?

Select the volume in the Finder and choose Get Info.

I assume you restored the volume by holding down the option key and choosing Archive > Restore Volume To... (or by dragging the archive volume icon, dropping it into the restore volume, and choosing the "Replace Volume" option when the dialog popped up).

No; I backed out to the first level of the archive, right-clicked on the volume, and selected "Restore". Is that valid?

That was probably OK. The plain vanilla Restore command will restore the captured volume to its original volume. After reformatting a drive, however, the volume appears to be a new volume and QRecall might not recognize it as the original volume. In this case, the Archive > Restore Volume To... is the command of choice.

Did you try blessing the volume after restoring it?

Shades of System 9! Not even sure how I'd do this on OS X...but no. I didn't have any way of mounting the volume.

There's a bless terminal command, but I don't think that is your problem.

Hm. I misspoke: I had Show Invisible Items turned on, now Show Deleted Items.

(It's been a long night...)

I am debating whether or not to try it again-- it would be nice if it worked, since I wouldn't have to beg indulgences from Adobe and Microsoft...

Hi David (and other),

Did you solve it?

Usually i need to re-install the boot loader on my ihack in order to boot.

1. backup
2. re-install boot loader on the backup drive
3. reboot

Should work

Hope that help!

I wound up reinstalling the OS with a test user account, then using QRecall to restore my user account and selected apps. Fortunately it wasn't necessary to call Microsoft or Adobe.

James Bucanek wrote:

After formatting the new drive, and before restoring, make sure the "Ignore ownership and permission" option was not checked.

Please confirm that this admonition applies only to Restore and not to Capture. I back up two computers from two different user accounts to the same archive, mounted on one of those computers, and find that I need "ignore ownership . . ." to make that work.

Ralph Strauch wrote:Please confirm that this admonition applies only to Restore and not to Capture.

This issue applies to both restore and capture of a bootable OS X system volume. Note that it does not apply to volume containing the QRecall archive, and it doesn't matter (as much) if the volume just contains document files.

The files in a bootable OS X system require very specific ownership, permission, attributes to be set or it will not function. When QRecall captures a bootable OS X system, it records these properties in the archive. When it restores the files, it replicates the original file's ownership, permissions, and all attribute properties.

On a volume set to "Ignore Ownership and Permissions," the filesystem neither reports nor honers the ownership, permission, or attributes of files. When queried, all files appear to belong to the user that's requesting the information. All attempts to change the ownership, or set certain attributes, are ignored.

If you attach a bootable OS X system volume to another computer, and the volume is set to "ignore ownership and permissions," the volume will be captured but the metadata required to make it a bootable OS X system volume will have been lost. Similarly, if you take a successfully captured OS X system volume and restore it to a volume that ignores ownership, the necessary ownership and attribute will not be restored (because the filesystem will ignore them) and the volume will not be bootable.

Which brings us to a common problem when restoring a bootable volume, and why I posted the original comment. If you (a) capture you startup volume, (b) format a new drive, (c) attach it an external volumes and (d) restore your startup volume to the new drive, you have to be careful that the newly formatted volume didn't default to "ignore ownership," which is typical for external volumes. The lastest version of QRecall will warn you that you are recalling items that were captured on a volume that honors ownership and permissions, but you are now attempting to restore them to a volume that ignores it.

Sidebar: the "ignore ownership" attribute is not recorded on the volume. It's a flag (in a database) maintained by each system. When you attach a volume, OS X looks up the volume's identifier in its database and applies the "ignore ownership" flag based on that information. Thus, a volume that "ignores ownership" on one system might honor ownership when plugged into a different system. Similarly, if you wipe and reinstall your OS, or boot from another volume, the "ignore ownership" setting for your volumes could change.

I hope that this adequately explains the situation.

That's reassuring. Thanks for the clear explanation.