Unable To Browse Client

[Guest Steve Maser]

This is something that's supposed to be fixed in the upcoming release (a new client is among that that purports to solve the problem...)

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

Hello

 

Registered to say I'm seeing the same problem.

 

My setup:

Server: Intel Mac Pro (Mac OS X 10.6.8)

Client: PPC Xserve G5 (Mac OS X Server 10.5.8)

 

Having recently moved our retrospect server to an Intel based box I am no longer able to list/browse shares of our Xserve running the Retrospect client.

There were no problems with share listing from the client to the server prior to the switch to Intel. (the problem was speed or rather the lack thereof).

 

- I have tried reinstalling the retrospect client on the xserve, rebooting the xserve but still nothing showed up.

- I have tried removing the client/share from the retrospect server. And re-adding it. Both via Discovery and via IP-address.

- I've tried using a key pair and installing the client with the key included. None of this helped either.

 

I contacted support the other day but was shun off today with a mail about me not having ASM...

That has to be one of the most arrogant things I've ever experienced.

The software performs terribly and is full of bugs for which fixes never come and we then have to pay $69 for "single issue support"... LOL

I've been waiting 2 years for Retrospect 8 to be fixed and updating my hardware to better match Retrospect recommendations only lands me new bugs and a request to throw money at Roxio.... Nice.

 

 

[c3768c36-bf22-4c6d-bc39-cdddd3062225]

I haven't been messing with R v.8 for a while. We're back to 6 - but even that is giving us issues. The same setup that was pretty solid, albeit extremely slow on a G4, is now unusable on our G5. In desperation I've moved our SCSI card along with our VXA drive to a MacPro. Since then I've only managed to get between 100 MB and around 30 GB on a tape before I get a 204 error. This is typically a device busy/device in use type of error and I cannot for the life of me determine why this is happening. The terminal tools for the VXA allow me to run a r/w test to the device, which I previously did while on the G5 with no issues. So I have apparent hardware issues now in 6 and software issues with 8. I have 360 GB of completed projects that need to be moved to tape so we can move the 100s of GB from our local machines to our completed "drive" (a shared folder on a 500GB RAID). Today I will fire up v.8 again from the MacPro and see if I can at least get our completed projects moved. This is ridiculous from a hardware/software standpoint. If someone would step up with a great piece of Mac software for tape I'd be all over it.

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

Registered to say I'm seeing the same problem.

 

My setup:

Server: Intel Mac Pro (Mac OS X 10.6.8)

Client: PPC Xserve G5 (Mac OS X Server 10.5.8)

 

And there's the culprit.

Installed Leopard (10.5) on the server and set up Retrospect. This enabled me to correctly see and browse the client.

 

Then I tried to add my NAS share in Retrospect and it kept saying "Invalid credentials".... Tried connecting to the share via Finder and everything was fine. Retried in Retro and OS X died with Kernel Panic.

Oh well I thought to myself. Retrospect crapping its pants once is okay.

 

So I rebooted, stopped the retroengine and tried transferring settings (/Library/Application Support/Retrospect/) from the old G5 (where the NAS share was added fine).

Started Retrospect Engine and BOOM! Kernel Panic.

Rebooted and... Kernel Panic as soon as Retrospect Engine came online.

 

Set up a Mac Mini with OS X 10.5.8 and Retrospect Server. Tried adding the NAS... Kernel Panic!

 

 

So far I'm unable to use Retrospect 8 with Intel machines with either OS X 10.5 or 10.6.

 

This has to be the worst architecture move I've ever seen.

[c3768c36-bf22-4c6d-bc39-cdddd3062225]

Ugh - I'm at my wit's end now. Set up v.8 on our MacPro - set up clients, set up a script, sources, etc., etc., - we have about 360 GB of data that needs to be archived. Everything seemed to be working (gasp) - I had over 150 GB written to tape, was running at about 800mb/min. I added the second tape, assuming that by the next morning we'd be verifying and everything would be fine. Sometime that evening the Retrospect Engine quit. Upon restarting the Engine the app re-established its connection. There's no indication in the app that the script finished or failed. Upon running the script again, it appears to start over disregarding the previous 150 GB of data, but asking for a new member (ala tape 2). So I assume that because the data wasn't verified that it never actually added it to the catalog - but it wants to start with a new member?

 

So whatever, I decide to go with the flow - hoping that Retrospect knows best. So tape 2 starts to back up. Getting horrible r/w speeds. Around the 60mb/min range. Frustrated, I just let it go. By late afternoon it wants new media. But has only backed up 20GB! So start over. From scratch. Erase the tapes, delete and redo the script, everything. This was Friday afternoon at this point. I set everything to go again and by the time I leave we're running a bit slower than before (200/300mb/min) but it seems to be going. I leave, fingers crossed, hoping to come in over the weekend and just switch tapes.

 

Sunday - the Engine has quit again. I restart the engine, only 2GB are confirmed to be backed up. I run the script again, tape 1 is still in the drive. It asks for another tape. So something is obviously screwy here. But I oblige - insert a new blank tape, it starts to run. All I can do is leave. This morning the engine has quit again. I'm at a loss now. There seems to be nothing in place from a software standpoint to deal with a quitting engine. I've review the logs in the Console and plainly see where the engine quits, but there's not much more to it. Anyone who thinks they may get some valuable info from the logs, let me know and I'll post it.

 

I think at this point I'm going to roll all the way back to the G4 that worked with v. 6 - albeit extremely slowly. And research alternative software compatible with our VXA moving forward. This is ridiculous.

[f30e6e60-a263-4d69-8f60-c92703669308]

 

 

Retried in Retro and OS X died with Kernel Panic.

Oh well I thought to myself. Retrospect crapping its pants once is okay.

 

 

And you're convinced that Retrospect 8 (either the RetroEngine process or the Retrospect.app console application) is causing a low level kernel panic?

 

Even though you're seeing the crashes occur alongside software, kernel panics are generally associated more with hardware or hardware drivers then they are with higher level software.

 

You provided only a brief description of your configuration or of the hardware you're using, so it's impossible to know specific steps you're taking.

 

But kernel panics provide a log; what do you see there?

[c3768c36-bf22-4c6d-bc39-cdddd3062225]

And you're convinced that Retrospect 8 (either the RetroEngine process or the Retrospect.app console application) is causing a low level kernel panic?

 

Even though you're seeing the crashes occur alongside software, kernel panics are generally associated more with hardware or hardware drivers then they are with higher level software.

 

You provided only a brief description of your configuration or of the hardware you're using, so it's impossible to know specific steps you're taking.

 

But kernel panics provide a log; what do you see there?

 

I second this - Kernel Panics are almost always hardware related. Can be quite the pain to track down. RAM is the usual culprit, could also be the logic board, power supply or hard drive.

[f30e6e60-a263-4d69-8f60-c92703669308]

i also recognize you're seeing this on two different Macintosh computers. And certainly bringing in a second test bed can add weight to a theory. But you would still have to confirm what, if anything, is common between the two machines other then Retrospect. This is where full and complete setup descriptions are essential.

 

 

 

Dave

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

i also recognize you're seeing this on two different Macintosh computers. And certainly bringing in a second test bed can add weight to a theory. But you would still have to confirm what, if anything, is common between the two machines other then Retrospect. This is where full and complete setup descriptions are essential.

 

 

 

Dave

 

Thank you for your reply.

I'll get the complete machine details and post it.

 

Reproducing the Kernel Panic overlay screen is pretty straight-forward on both machines.

- Click "Sources"

- "+ Add"

- "Add share" button

- Enter "afp://10.0.0.14/backup" and the user+password

- Click "add" button a couple times while getting the "invalid credentials" error.

- Kernel Panic

 

My immediate suspicion is a conflict between Retrospect server 8.2 afp share login handling and the 10.5.8 network driver.

 

As to whether it's a hardware problem I have to say a big no. Seeing as adding the share in Retrospect 8 while the machines run 10.6.8 is no problem.

In 10.6 I can't see the shares on the client though... Hence trying to get this up and running on 10.5...

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

Network setup:

- Netgear ReadyNAS with one share for backup

- Cisco Switch

- Machine running Retrospect engine

 

 

Retrospect server 1 HW: (this is the only working one so far...)

Dual-core PowerPC G5

3,5 GB RAM

Mac OS X 10.5.8

 

Retrospect server 2 HW:

Model Name: MacPro

Model Identifier: MacPro1,1

Processor Name: Dual-Core Intel Xeon

Processor Speed: 2,66 GHz

Number Of Processors: 2

Total Number Of Cores: 4

L2 Cache (per processor): 4 MB

Memory: 3 GB

Bus Speed: 1,33 GHz

Boot ROM Version: MP11.005C.B08

SMC Version (system): 1.7f10

Retrospect server 3 HW:

Model Name: Macmini

Model Identifier: Macmini3,1

Processor Name: Intel Core 2 Duo

Processor Speed: 2,26 GHz

Number Of Processors: 1

Total Number Of Cores: 2

L2 Cache: 3 MB

Memory: 2 GB

Bus Speed: 1,07 GHz

Boot ROM Version: MM31.00AD.B00

SMC Version (system): 1.35f1

 

 

Notes:

When server 2 runs Snow Leopard (10.6.8) there are no problems adding the network share as a source. But it is unable to list shares on the client.

When server 2+3 run Leopard trying to add the network share results in Kernel Panic.

 

I've attached the Console Panic logs. As far as I could read they say "Retrospect"...

 

Excerpt of a panic log:

Thu Aug 18 11:42:15 2011

panic(cpu 2 caller 0x001AB0FE): Kernel trap at 0x0017f403, type 14=page fault, registers:

CR0: 0x80010033, CR2: 0xc0070014, CR3: 0x39181000, CR4: 0x00000660

EAX: 0x00000001, EBX: 0xc0070000, ECX: 0x095605d0, EDX: 0x094abe38

CR2: 0xc0070014, EBP: 0x4a31f8c8, ESI: 0x00000000, EDI: 0x00000000

EFL: 0x00010286, EIP: 0x0017f403, CS: 0x00000008, DS: 0x012c0010

Error code: 0x00000000

 

Backtrace (CPU 2), Frame : Return Address (4 potential args on stack)

0x4a31f6c8 : 0x12b4c6 (0x45f91c 0x4a31f6fc 0x13355c 0x0)

0x4a31f718 : 0x1ab0fe (0x469a98 0x17f403 0xe 0x469248)

0x4a31f7f8 : 0x1a1713 (0x4a31f810 0xe00002d8 0x4a31f8c8 0x17f403)

0x4a31f808 : 0x17f403 (0xe 0x4a310048 0x4a310010 0x4a310010)

0x4a31f8c8 : 0x162d9a (0x94abe38 0x0 0x0 0x3)

0x4a31fa38 : 0x1aaeaf (0x1ec1d14 0x3d3f3000 0x0 0x3)

0x4a31fb18 : 0x1a1713 (0x4a31fb30 0x53d63c 0x4a31fbc8 0x4b01e670)

0x4a31fb28 : 0x4b01e670 (0xe 0x360e0048 0x4a310010 0x420010)

0x4a31fbc8 : 0x4b01ef09 (0x360e1000 0x3d3f3000 0x4000 0x4b019583)

0x4a31fc08 : 0x4b01f6f8 (0x360e1000 0x360e10c8 0x40000 0x4115eb)

0x4a31fc58 : 0x4b07711e (0x360e1000 0x360b6000 0x621bd80 0x621bd80)

0x4a31fc78 : 0x4b0375a9 (0x360e1000 0x360b6000 0x4a31fca8 0x4195d1)

0x4a31fc98 : 0x4b03bf99 (0x360e1000 0x360b6000 0x4a31fcd8 0x412a65)

0x4a31fcb8 : 0x4b03e349 (0x360e1000 0x360b6000 0x6cfc340 0x360e1000)

0x4a31fcd8 : 0x4b017aaf (0x360e1000 0x360b6000 0x74e2000 0x725708c)

0x4a31fd08 : 0x415e83 (0x360b6000 0x621fbe4 0x621fbe4 0x1)

Backtrace continues...

Kernel loadable modules in backtrace (with dependencies):

com.apple.GeForce(5.4.8)@0x4b004000->0x4b09bfff

dependency: com.apple.NVDAResman(5.4.8)@0x4aa9e000

dependency: com.apple.iokit.IONDRVSupport(1.7.3)@0x4aa52000

dependency: com.apple.iokit.IOPCIFamily(2.6)@0x42a2e000

dependency: com.apple.iokit.IOGraphicsFamily(1.7.3)@0x4aa35000

 

BSD process name corresponding to current thread: Retrospect

 

Mac OS version:

9L31a

 

Kernel version:

Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386

System model name: MacPro1,1 (Mac-F4208DC8)

 

System uptime in nanoseconds: 1741237063950

unloaded kexts:

com.apple.driver.AppleHDAPlatformDriver 1.7.1a2 - last unloaded 92263018719

loaded kexts:

com.apple.filesystems.afpfs 9.0.2 - last loaded 1429514116024

com.apple.nke.asp_tcp 4.7.1

com.apple.filesystems.msdosfs 1.5.5

com.apple.driver.AppleHWSensor 1.9d0

com.apple.driver.AppleUpstreamUserClient 2.7.5

com.apple.filesystems.autofs 2.0.2

com.apple.Dont_Steal_Mac_OS_X 6.0.3

com.apple.GeForce 5.4.8

com.apple.driver.AppleHDA 1.7.1a2

com.apple.driver.AudioIPCDriver 1.0.6

com.apple.driver.AppleMCEDriver 1.1.7

com.apple.driver.AppleHDAController 1.7.1a2

com.apple.iokit.IOFireWireIP 1.7.7

com.apple.driver.ACPI_SMC_PlatformPlugin 3.4.0a17

com.apple.driver.AppleLPC 1.3.1

com.apple.nvidia.nv40hal 5.4.8

com.apple.driver.AppleHIDKeyboard 1.0.9b4

com.apple.driver.AppleUSBComposite 3.2.0

com.apple.iokit.SCSITaskUserClient 2.1.1

com.apple.iokit.IOSCSIMultimediaCommandsDevice 2.1.1

com.apple.driver.XsanFilter 2.7.91

com.apple.iokit.IOATAPIProtocolTransport 1.5.3

com.apple.driver.AppleIntel8254XEthernet 2.1.2b1

com.apple.driver.AppleUSBHub 3.4.9

com.apple.iokit.IOAHCIBlockStorage 1.2.2

com.apple.iokit.IOUSBUserClient 3.4.9

com.apple.driver.AppleEFINVRAM 1.2.0

com.apple.driver.AppleFWOHCI 3.9.7

com.apple.driver.AppleIntelPIIXATA 2.0.1

com.apple.driver.AppleUSBEHCI 3.4.6

com.apple.driver.AppleAHCIPort 1.7.0

com.apple.driver.AppleUSBUHCI 3.3.5

com.apple.driver.AppleACPIButtons 1.2.5

com.apple.driver.AppleRTC 1.2.3

com.apple.driver.AppleHPET 1.4

com.apple.driver.AppleACPIPCI 1.2.5

com.apple.driver.AppleSMBIOS 1.4

com.apple.driver.AppleACPIEC 1.2.5

com.apple.driver.AppleAPIC 1.4

com.apple.security.TMSafetyNet 3

com.apple.security.seatbelt 107.12

com.apple.nke.applicationfirewall 1.6.77

com.apple.driver.DiskImages 199

com.apple.BootCache 30.4

com.apple.driver.AppleIntelCPUPowerManagement 76.2.0

com.apple.driver.DspFuncLib 1.7.1a2

com.apple.iokit.IOAudioFamily 1.6.9fc5

com.apple.kext.OSvKernDSPLib 1.1

com.apple.iokit.IOHDAFamily 1.7.1a2

com.apple.driver.IOPlatformPluginFamily 3.4.0a17

com.apple.driver.AppleSMC 2.3.1d1

com.apple.NVDAResman 5.4.8

com.apple.iokit.IONDRVSupport 1.7.3

com.apple.iokit.IOGraphicsFamily 1.7.3

com.apple.iokit.IOUSBHIDDriver 3.4.6

com.apple.iokit.IOBDStorageFamily 1.5

com.apple.iokit.IOSCSIBlockCommandsDevice 2.1.1

com.apple.iokit.IODVDStorageFamily 1.5

com.apple.iokit.IOCDStorageFamily 1.5

com.apple.iokit.IOSCSIArchitectureModelFamily 2.1.1

com.apple.iokit.IONetworkingFamily 1.6.1

com.apple.iokit.IOFireWireFamily 3.4.9

com.apple.iokit.IOATAFamily 2.0.1

com.apple.iokit.IOAHCIFamily 1.5.0

com.apple.iokit.IOUSBFamily 3.4.9

com.apple.driver.AppleEFIRuntime 1.2.0

com.apple.iokit.IOSMBusFamily 1.1

com.apple.iokit.IOHIDFamily 1.5.5

com.apple.iokit.IOStorageFamily 1.5.6

com.apple.driver.AppleACPIPlatform 1.2.5

com.apple.iokit.IOACPIFamily 1.2.0

com.apple.iokit.IOPCIFamily 2.6

 

Do note!: There are no Kernel Panics in 10.6.8 when adding the exact same share.

Edited August 23, 2011 by Ole_J

[f30e6e60-a263-4d69-8f60-c92703669308]

When server 2+3 run Leopard trying to add the network share results in Kernel Panic.

 

Have you tried adding a volume from a different file sharing host device, instead of the ReadyNAS? Perhaps one of the other Macs?

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

Have you tried adding a volume from a different file sharing host device, instead of the ReadyNAS? Perhaps one of the other Macs?

 

That's a good suggestion.

I've just tested and the result was exactly the same.

The share I tried to access is an AFP share on the Xserve G5 (OS X 10.5 Server).

 

Exactly the same behaviour. First it says "invalid credentials" and then 5 seconds later I get Kernel Panic. :-(

 

Did I mention that Cmd+K to the share works flawlessly? And that adding the share in Retrospect on 10.6 on the same machines works fine as well...

 

Next I'm going to try adding SMB to the ReadyNAS share and see if that plays nicely. If that fixes it and I'm not in for yet another round of problems then that's what I'll use.

 

All this trouble because Retrospect under 10.6.8 doesn't list the clients drives/shares.

Edited August 24, 2011 by Ole_J

[f30e6e60-a263-4d69-8f60-c92703669308]

All this trouble because Retrospect under 10.6.8 doesn't list the clients drives/shares.

 

 

Yes, it does, in my installation. I have had no problem connecting from the Engine hosted on a Mini Server 10.6.8 via AFP to shares on Macs and AirPort Extreme, as well as SMB hosted by some ancient Maxtor consumer NAS.

 

The MacPro1,1 shipped with 1GB RAM standard; where did the additional RAM come from? Can you fall back to the Apple supplied RAM and test?

 

The Macmini3,1 shipped with either 1GB or 2GB RAM standard (depending on if was early or late 2009). Does the Mini have third party RAM installed?

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

Yes, it does, in my installation. I have had no problem connecting from the Engine hosted on a Mini Server 10.6.8 via AFP to shares on Macs and AirPort Extreme, as well as SMB hosted by some ancient Maxtor consumer NAS.

 

The MacPro1,1 shipped with 1GB RAM standard; where did the additional RAM come from? Can you fall back to the Apple supplied RAM and test?

 

The Macmini3,1 shipped with either 1GB or 2GB RAM standard (depending on if was early or late 2009). Does the Mini have third party RAM installed?

 

The Mac Mini uses only original Apple supplied RAM.

I have no trouble adding the shares via CMD+K in Finder and accessing them this way. It works flawlessly.

 

I have absolutely no problems running the engine on OSX 10.6 AND adding/using the NAS as a source. But the Engine on Intel+10.6 refuses to list the drives of the Client on the Xserve G5 (PPC)... Which brings it back to the OP of this thread. (No triangle in front of the client in the sources list, etc. etc.).

 

As mentioned I'll be testing if SMB (or NFS for that matter) will fix it for me.

 

I'm happy to know that it works for you on 10.6.8. But then that's opposite of what you post at the top of the page...

There should, however, be a disclosure triangle to the left of the client name as soon as the client is added, even if no other action has been taken. This is what's missing in dburney's screenshot

Yep; that's the crux of the issue, for me as well as dburney.

Thank you.

 

Edit: The Mac Pro is out of the equation for now as it has been put to use for other tasks.

Edited August 25, 2011 by Ole_J

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

I have just had a success experience.

Did a clean 10.6.0 install on the mini and adding the NAS worked as it should. And with great joy I can report that the drives on the client were also listed correctly.

I am just now running a full software update on the mini and will return with an update.

Perhaps there's light at the end of the tunnel

Edited August 25, 2011 by Ole_J

[29e592b6-6d49-4c32-91e7-4f054eaf5b85]

So far so good!

Thank you guys for your help. I now have a working solution.

 

Now that it's not broken I shall try not to fix it