Jump to content
Sign in to follow this  
Monafly

Dual boot-getting both to back up

Recommended Posts

I've got a Macbook Pro laptop that has two partitions and is set up to allow dual boot. One is 10.6.8 and the other is 10.12.x

 

The problem is that for some reason, RS won't recognize each as a unique machine, so I have so far had to reconfigure RS (the server) every time I want a backup to run. Part of this problem may be that regardless of which boot is used, it picks up the same IP and seems to also have the same machine name (even though the names do appear to be unique in System Preferences). 

 
 

I'm running RS 13 engine in proactive mode on another machine with this laptop as a client. The client has been installed in both partitions. Under 10.6.8 boot, the 10.12 partition can't be seen (this is an Apple issue that I can't seem to get around). When booting under 10.12.x, both partitions are visible and 'could' be set up to have favorites on both that would be backed up. The more common boot is 10.6.8 at the present time, leaving the 10.12.x partition unprotected regardless of how it's booted until I reconfigure RS clients. 

 

 

What am I missing here?

 

 

Share this post


Link to post
Share on other sites

Sorry, but this was mis-posted to the bug reports list rather than the regular questions list. 

 

I found the solution (described in more detail in the regular list), but to summarize:

 

Solution:

Uninstalling the RS client and reinstalling it in one of the partitions allowed them both to be recognized as unique. 

 

If anything might be an RS bug it would be that changing the machine name in the Mac OS is not propagated to the RS client unless one uninstalls and reinstalls the client, at which point the new name is recognized. There might be other reasons why this is not a good idea, so I'll leave it to RS to decide whether it is truly a bug or not. 

Share this post


Link to post
Share on other sites

Monafly's more-fully-described solution to the first problem (in his second paragraph) in his OP is here.  He has also, in the same linked-to post, provided convincing evidence that he/she indeed can't easily solve the second problem (in his third paragraph) in his OP.

 

IMHO, there is no likelihood that Retrospect Inc. would try to prevent the first problem from occurring—so Monafly shouldn't bother reporting it as a bug.  The engineers would undoubtedly take the position that Monafly should have created the unique machine name for his macOS 10.12.x partition before installing the Retrospect Client the first time.  They would ignore the fact that this requirement is not documented in the Retrospect Mac 13 User's Guide.

 

However there is the barest chance that Retrospect Inc. might try to fix the second problem.  Monafly almost certainly isn't the only Retrospect Mac user with a laptop that has partitions for both OS X 10.6.8 and a more recent version of OS X/macOS.  I assume that most such users have to keep the 10.6.8 partition because they are using apps that only run with Rosetta's PowerPC emulation (that's why I have never updated from OS X 10.6.8 on Ronny Lee's separate drive—or what is now a partition on that separate drive—on the Mac Pro I inherited from him).  If Monafly wants to submit the second problem as a bug, he/she should follow the procedure described in the second paragraph of post #3 in the thread linked to in the first sentence of this post.  However realistically the chances of Retrospect Inc.'s engineers being able to fix it are slim, because they would have to add code to the Retrospect Mac client that essentially duplicates Core Storage access code in more recent versions of macOS (and how are they going to get Apple to give it to them?).  IMHO Monafly would do better to first back up his/her 10.12.x partition, and then to try to revert that partition back to HFS+ using the procedure in the second link in his/her post linked-to in the first sentence of this post.

Share this post


Link to post
Share on other sites

On further thought, I retract the statement in the fifth sentence of my third paragraph in post #3.  Retrospect would probably not have to get Apple to give them the Core Storage access code, because Apple has almost certainly released it as part of Darwin.  So go ahead and submit your second problem as a bug, Monafly; the Retrospect Inc. engineers may in fact be able to fix it.

 

P.S.: What I recommended in the sixth sentence of my third paragraph in post #3 will still probably solve Monafly's second problem faster than submitting it as a bug, but if he/she has the patience then more power to him/her (insert appropriate smiley here).

 

P.P.S.: Oops.  In the second sentence I intended to write "Retrospect [my emphasis] would probably not have to get Apple to give them the Core Storage access code ..."

Share this post


Link to post
Share on other sites

I posted about this problem in an Ars Technica Macintoshian Achaia forum, and it turns out I guessed wrong in the first paragraph of post #4.  Core Storage is not part of the code that Apple has released as part of Darwin.  So if you haven't yet submitted your second problem as a Retrospect bug, Monafly, I would say don't bother—Retrospect Inc. probably won't be able to fix it.  Sorry.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×