Cannot connect to Mac after 6.1.126 update

[denim]

So we can delete the older version of this file w/o disturbing our (possibly many) scripts?

[GD1]

same problem as everybody else: after installing 6.1.126 Retrospect works with my Mac running Tiger, Maxtor touch One II formated for Mac, BUT the 2 do not connect. 'No device'

 

Any suggestions? maxtor help aparently not aware yet of 6.1.126 release.

 

Help!

GD

[Mayoff]

The only solution for the client issue right now is an uninstall and reinstall.

[brendan]

I have three macs being backed up remotely, all running 10.4.2. After updating the server to 6.1, I could not connect with two of the clients to upgrade them to 6.1 client via the push update. The third machine connected just fine and allowed me to perform the client update. After the update, still fine. The other two machines I updated manually. After the update, they still could not connect.

 

 

 

Following the directive here, I tried uninstalling/reinstalling one client. After forgetting and re-adding that client, it was fine. The second machine I did not do the uninstall/reinstall. Instead I just forgot and re-added the existing client. It also started working.

 

 

 

So, it's not a client issue and it does not appear to require uninstalling and reinstalling. Just forget and re-add (and update your scripts accordingly).

 

 

 

I should also note that the machine that was working fine all the way through is one that I just added to the backup plan a few weeks ago. The other two have been getting backed up by Retrospect for many months. So perhaps this is some kind of legacy issue rearing its ugly head?

[nevai]

Forget and re-add did not work for me.

 

Forget, reinstall, and re-add worked on one of my macs. I have not worked on the other mac yet.

Will do it tomorrow.

 

My pc works with the old client. I will install the new one tomorrow and check it out.

 

/Paul

[twickland]

Quote:

---

Any scripts (including backup server scripts) would have to be edited to add the forgotten/re-added client

 

---

 

It can be a lot easier to manipulate (forget/reinstall) clients if you create client groups in the Volumes menu. We then use the appropriate client group(s) as the source for each script, instead of a list of individual client volumes.

 

Then, when adding a client, we simply need to drag it once to the appropriate group in the Volumes menu, instead of having to edit the new client into each script.

[rhwalker]

Quote:

---

Hopefully the pool of possible testers doesn't run out before the actual cause is discovered!

 

 

---

 

David, if it would help, I could hold off on doing the update to preserve a testbed site. I've got a very simple installation (Xserve G5 Mac OS 10.4.2 server running Retrospect Workgroup 6.0 current with Retrospect 6.0 updates, backing up 3 Mac 10.4.2 clients (current with Retrospect 6.0 client) and two Mac OS 9 clients). It is no great effort to uninstall/install 3 Mac OS 10.4.2 clients in the one script that backs up the networked clients, so, if that's a fix I wouldn't be inconvenienced by doing the install now, but I could certainly wait if it would help because everything is working now with Retrospect 6.0. There could actually be a benefit in waiting because, from the release notes, once Retrospect 6.1 writes to a backup set, Retrospect 6.0 can't use that set any longer. If I had to downgrade back to Retrospect 6.0 if no joy on upgrade, that would mean abandoning the VXA-2 rotating backup tape set in use in our Exabyte autoloader and starting all new media for downgraded Retrospect 6.0, and that would be somewhat expensive. There's also the issue of a bare-metal restore with Retrospect 6.1, if it should prove necessary, which would be difficult but not impossible until a Retrospect 6.1 disaster recovery disk image is posted, but I've burned a CD with the 6.1 install files on it so I think that I could come forward from the Mac OS X 10.4 Server install DVD if a disaster restore was necessary.

 

Let me know if you want to preserve a simple un-updated testbed site for testing a future fix. Regards, Russ

[jroberts]

Same issue here... Server is 10.4.2, I installed 6.1.126 and then get net retry errors when I try to configure any OSX clients regardless of client software version. OS9 and Windows clients work fine. Manually running the client update does not fix it. Forgetting and re-logging in an OSX client after manually updating the client does not fix it. Uninstalling and then reinstalling the client which then results in having to log the client in again as a new client does fix it.

 

This will be a painful process on our 70+ OSX clients...

[jclark]

If uninstalling/reinstalling is an issue, the fix ought be that the Installer automagically provides this function - and this has been an issue sinnce OSX was first supported [ IIRC ].

 

When upgrading to the new Client, the Installer first un-installs the old client, reboots the Mac, then causes itsellf to launch on login, and has you push the Install button for the New Client. Then reboot.

 

Whew!

 

Would save us all a lot of typing on this board...

 

jeff

[tkw4u2]

My experiences say that the issue lies with the server, not the client. I installed the server product first and immediately all the clients were inaccessible. None of them had been upgraded to the new client yet. Did the upgrade using the server method and all updated fine but they still had the same problem. Also, all of the clients were accesible from the old server software with both versions of the client.

 

I did have a very weird fix happen with this today. Installed everything as described above yesterday. I had two clients I couldn't do an uninstall/reinstall on. Both failed on the backup last night. Suddenly this morning when I ran a manual backup both clients are working correctly. Now why would it take 12 - 16 hours of sitting to suddenly allow those clients to connect with no additional work on my part?

[indigovic]

My situation is a little bit different in that I have some clients succeeding, but most failing.

 

 

 

• Updated backup server (running on OS 10.3.8 Server) to Retrospect 6.1, then pushed client updates to all clients. Retrospect declared all updates successful.

 

 

 

• Backing up Windows clients succeeded.

 

• Backing up 2 Mac OS X 10.4.2 Server OS clients succeeded (have not rebooted machines)

 

• All other Mac clients EXCEPT one - mostly 10.3.9, a few lower 10.3.x (including two 10.3.8 Server OS), and a couple of 10.4.x failed. Some of them were running 6.0.108, some 6.0.109, and some 6.0.110 previous to the update.

 

• One 10.3.9 eMac, which, best as I can tell, is virtually identical to at least one of the other failed clients in both model and OS, succeeded. The only difference I can think of is that I *think* that one machine's initial install was 6.0.109, and was never updated to 6.0.110. The otherwise identical machine was also updated from 6.0.109, but it *probably* started with a version lower than that. In fact, this one machine that succeeded *may* be the only one I've got that only *ever* had 6.0.109 on it.

 

 

 

-Vic.

 

.

[ernst_mulder]

What does the client uninstall do exactly?

 

When I do the following:

 

1) forget client on backup machine

2) sudo killall pitond on client

3) sudo rm /Library/Preferences/retroclient.state on client

4) sudo rm -r /Applications/Retrospect\ Client.app

5) reinstall client

6) sudo killall pitond, unmount installer image, start client*

7) reconnect to the client on the backup machine

 

the problem persisis.

 

When I do the following:

 

1) forget client on backup machine

2) sudo killall pitond on client

3) uninstall the client using the client installer

4) immediately reinstall the client

5) sudo killall pitond, unmount installer image, start client*

6) reconnect to the client on the backup machine

 

the problem is solved.

 

So , what's thate xtra thing the uninstaller does? I did notice it clears the logs matching /var/log/retro* some of which were quite big, my retropds.log for instance was 241MB. Something worthwhile to look at?

 

*The retrospect client installer STILL auto-launches pitond from the installer disk image, can this please be solved one day? Instead of restarting the client Mac I kill the pitond after installation and start the client again which has essentially the same effect.

 

Ernst Mulder

GrafiSIS & AdvieSIS BV

[ernst_mulder]

YES!!

 

I think I might have found the real cause (more testing underway).

 

Following up on my previous post, I went to another problematic machine. I did the following:

 

1) sudo killall pitond on client

2) sudo rm /var/log/retropds.log (which was 109MB)

3) started the retrospect client

 

problem solved, the server immediately connected again, no need even to forget/reconnect.

 

So please, testers, test with big /var/log/retropds.log files (I could send you one of mine if you want).

 

Ernst Mulder

GrafiSIS & AdvieSIS BV

[ernst_mulder]

More info:

 

 

 

Simply removing /var/log/retropds.log on the client machine even with the client running does the trick.

 

 

 

I've got all our clients up and running again without restarting anything (removed the troublesome logfiles using ssh) and without editing any scripts.

 

 

 

Does this mean however that the problem will return when that specific log file grows again in time?

 

 

 

Ernst Mulder

 

GrafiSIS & AdvieSIS BV

[michaeln]

Hi Ernst,

 

Thanks for the clear and detailed troubleshooting.

That was extremely helpful.

 

Would you (and others running into this problem) mind sending an email to forums@dantz.com and we'll direct you to an FTP site to upload the retropds.log file so that we can research this on our end?

[CallMeDave]

Quote:

---

Simply removing /var/log/retropds.log on the client machine even with the client running does the trick.

 

---

 

Woo Hoo! Great testing methodology, Ernst!

 

Dave

[michaeln]

Hi,

 

Just an update.

 

We have reproduced this in-house so no need for the retropds.log files.

Our engineers are working on a fix for this.

 

It appears that this happens with large retropds.log files which was a bug seen in certain environments with the prior version and is now fixed in 6.1 but obviously did not account for users that still had this problem.

 

I will notify this thread as soon as we have a fix.

 

Thanks again to everyone for their input and sleuthing.

[ernst_mulder]

You can download one of my troublesome retropds.log's here:

 

http://os36.grafisis.nl/dantz/

 

Ernst Mulder

GrafiSIS & AdvieSIS BV

 

---

 

Mail to forums@dantz.com bounces with the following result:

 

This is an automatically generated Delivery Status Notification.

 

Delivery to the following recipients failed.

 

CN=Robin Mayoff,OU=TS,OU=WC,DC=dantz,DC=com

[Mayoff]

Hi,

 

A workaround and cause can be found at the following URL:

 

http://kb.dantz.com/article.asp?article=8119&p=2

[CallMeDave]

Robin,

 

Based on what Michael said above ("which was a bug seen in certain environments with the prior version and is now fixed in 6.1") and what's written in the KB you reference ("This problem occurs because the Retrospect client is busy reducing the total size of the retropds.log file.") it's apparent that 6.1 has something in place to manage the log file (which, up until now, would grow and grow with each client session).

 

Can you tell us how 6.1 behaves now?

 

Thanks,

 

Dave

[Mayoff]

I don't have all the details myself. The installer is supposed to check the file to make sure it isn't over a specific size, and then purge it if needed. The purge process was running really slow with big log files, causing the netretry.

 

They fixed the slow purge. Michael may have more details.

[michaeln]

Hi,

 

Sorry for the late reply as I was on vacation and just got back.

 

So the retropds.log file is a debug log that gets written to everytime the client is accessed and is useful when investigating client related problems.

From my understanding, the bug in 6.0 was that there was no checking mechanism for the size of the log and therefore the log file could grow extremely large if the client was being accessed frequently.

 

In order to address this bug, 6.1 will now "groom" the retropds.log file if it gets over 10mb purging the old information. However the bug did not account for existing extremely large log files and so it was taking a long time to read the large file and then chopping down the file. The Retrospect server could not access the client while it was busy running this "groom" process which caused the "Net Retry" errors.

 

The new client download which should be available later today will contain an installer and RCU that deletes the retropds.log entirely so it doesn't run into this long "groom" process with large files.

 

Hope this answers it.

[Mayoff]

Some users have reported difficulty updating the Macintosh client software from 6.0 to 6.1. This reported problem resulted in NetRetry messages during the update process.

 

EMC Dantz has released an updated version of the 6.1 client installer and .rcu files for updating over the network which will resolve this problem.

 

The version of the client is still 6.1.107 but the installer itself has been updated. The new update can be found at:

 

http://www.dantz.com/en/support/updates.dtml#mac

[Mayoff]

I wanted to publicly thank Ernst Mulder for being the one to identify the cause of this problem. It was very helpful since we were unable to reproduce the issue at EMC until he posted his findings.

[ben23]

Hi,

 

 

 

I updated to Retrospect 6.1.126 and used the latest 6.1.107 client updates on all of my OS X clients (five of them 10.3.9, two of them 10.4.2, one of them 10.4.2 Server). I was getting that "Net Retry" message on the 10.4.2 Server computer when trying to back it up, however the regular 10.4.2 machines worked fine. I found this very helpful thread and removed the troublesome retropds.log file on the 10.4.2 Server and reapplied the client updater via the network, restarted, but it didn't solve my issue. So on 10.4.2 Server I searched via spotlight for all files named "retro" and deleted all of them, killed pitond, emptied the trash.

 

 

 

I restarted 10.4.2 Server and downloaded the latest 6.1.107 client installer that was released on the 10/12, restarted the machine again and then tried running the backup from my backup computer (running Retrospect 6.1.126). It still failed with a message "network communication failed" after trying the backup a couple of times, restarting 10.4.2 Server, and trying to back it up again - same message again.

 

 

 

Interestingly, if I use Retrospect 6.0.204 to run the backup instead of Retrospect 6.1.126 - everything works fine and it backs up the OS X Tiger clients (including the troublesome 10.4.2 Server) and Panther clients that are all running version 6.1.107 of the client. It kind of has me scratching my head why only 10.4.2 Server doesn't want to backup, but as long as the older version still works and it has for months, i'm fine with that.

 

 

 

I checked the Console on 10.4.2 Server and pasted the following message it gave when it had the "network communication failed" message:

 

 

 

 

 

Oct 14 09:59:45 fileserver crashdump[739]: retropds.23 crashed

 

Oct 14 09:59:45 fileserver crashdump[739]: crash report written to: /Library/Logs/CrashReporter/retropds.23.crash.log

 

 

 

Host Name: fileserver

 

Date/Time: 2005-10-14 09:59:43.894 -0700

 

OS Version: 10.4.2 (Build 8C47)

 

Report Version: 3

 

 

 

Command: retropds.23

 

Path: /Applications/Retrospect Client.app/Contents/Resources/retropds.23

 

Parent: pitond [155]

 

 

 

Version: 6.1.107 (6.1.107)

 

 

 

PID: 658

 

Thread: 0

 

 

 

Exception: EXC_BAD_ACCESS (0x0001)

 

Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0a000008

 

 

 

Thread 0 Crashed:

 

0 libSystem.B.dylib 0x90006b34 szone_free + 2792

 

1 libSystem.B.dylib 0x900f5970 acl_free + 16

 

2 retropds.23 0x0000a028 aclGetNodeAcl + 440 (aclutil.c:328)

 

3 retropds.23 0x0000a2d8 AclGetData + 196 (aclutil.c:432)

 

4 retropds.23 0x00004184 volAclSpec + 104 (rfsvol.c:69)

 

5 retropds.23 0x00004504 volGetExtendedData + 128 (rfsvol.c:191)

 

6 retropds.23 0x00004000 TransMain + 344 (retropds.c:161)

 

7 retropds.23 0x0001113c ServMain + 464 (servicelib.c:458)

 

8 retropds.23 0x00003758 _start + 392 (crt.c:267)

 

9 dyld 0x8fe01048 _dyld_start + 60

 

 

 

Thread 0 crashed with PPC Thread State 64:

 

srr0: 0x0000000090006b34 srr1: 0x000000000200f030 vrsave: 0x0000000000000000

 

cr: 0x44000442 xer: 0x0000000020000004 lr: 0x0000000090007144 ctr: 0x0000000090013860

 

r0: 0x0000000090007144 r1: 0x00000000bfffed00 r2: 0x0000000001800004 r3: 0x000000000000000d

 

r4: 0x0000000000000000 r5: 0x0000000000000004 r6: 0x0000000080808080 r7: 0x0000000000000003

 

r8: 0x0000000036353800 r9: 0x00000000bfffebc4 r10: 0x0000000000000000 r11: 0x00000000a0006510

 

r12: 0x0000000090013860 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000

 

r16: 0x0000000000000000 r17: 0x0000000000000400 r18: 0x0000000000000041 r19: 0x0000000000000000

 

r20: 0x000000000000003f r21: 0x000000000200007e r22: 0x0000000002000082 r23: 0x0000000001808200

 

r24: 0x0000000000000002 r25: 0x0000000000000001 r26: 0x0000000001807e00 r27: 0x0000000001800000

 

r28: 0x0000000000000002 r29: 0x0000000000000000 r30: 0x000000000a000000 r31: 0x000000009000605c

 

 

 

Binary Images Description:

 

0x1000 - 0x1afff retropds.23 /Applications/Retrospect Client.app/Contents/Resources/retropds.23

 

0x8fe00000 - 0x8fe51fff dyld 43.1 /usr/lib/dyld

 

0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib

 

0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib

 

0x90728000 - 0x90801fff com.apple.CoreFoundation 6.4.3 (368.12) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation

 

0x9084a000 - 0x9084afff com.apple.CoreServices 10.4 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices

 

0x9084c000 - 0x9094efff libicucore.A.dylib /usr/lib/libicucore.A.dylib

 

0x909a8000 - 0x90a2cfff libobjc.A.dylib /usr/lib/libobjc.A.dylib

 

0x90a56000 - 0x90acafff com.apple.framework.IOKit 1.4 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit

 

0x90ae4000 - 0x90af6fff libauto.dylib /usr/lib/libauto.dylib

 

0x90afd000 - 0x90dc2fff com.apple.CoreServices.CarbonCore 10.4.1 (611.1) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore

 

0x90e25000 - 0x90ea5fff com.apple.CoreServices.OSServices 4.0 (4.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices

 

0x90eef000 - 0x90f2ffff com.apple.CFNetwork 10.4.2 (80) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork

 

0x90f44000 - 0x90f5cfff com.apple.WebServices 1.1.2 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore

 

0x90f6c000 - 0x90feafff com.apple.SearchKit 1.0.3 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit

 

0x9102f000 - 0x91056fff com.apple.Metadata 1.1 (121.6) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata

 

0x91066000 - 0x91074fff libz.1.dylib /usr/lib/libz.1.dylib

 

0x91077000 - 0x91239fff com.apple.security 4.0.1 (223) /System/Library/Frameworks/Security.framework/Versions/A/Security

 

0x9133b000 - 0x91344fff com.apple.DiskArbitration 2.1 /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration

 

0x9134b000 - 0x91372fff com.apple.SystemConfiguration 1.8.0 /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration