Jump to content
Sign in to follow this  
Mayoff

Elem.c-812 workarounds

Recommended Posts

This appears to be an OS 9 client problem...

 

 

 

OS 9 clients don't require Retrospect 5...

 

 

 

I thought the temporary solution would be obvious...

 

 

Share this post


Link to post
Share on other sites

I was my understanding that the problem occurs on client computers running OS 9 which also have personal file sharing turned on? I haven't heard of problems with clients running OS X but I may have missed them...

 

 

 

My suggestion was to run Retrospect 4.3 to back up the problematic OS 9 clients.(Even if you have upgraded the clients to version 5 I think Retrospect 4.3 can still see and use them)

 

 

 

Adrian

 

 

 

(see my other posts in this thread for the workaround I have been using)

Share this post


Link to post
Share on other sites

So the saga continues. Today I restored my old backup server to working order, a 7200/90 running Retrospect 4.3 with a DDS-3. I forgot all the clients and the logged in to my ASIP 6.3 file server and my ASIP 6.3 print server. I set them up to backup.

 

 

 

Then, after my Retrospect 5.0 server, a G3 266 with OS 9.2.2 and 384MB RAM (200MB to Retro 5) and a 70GB AIT mysteriously crashed (Illegal Instruction error at boot, extensions on or off - tried all testing to resolve), I rebuilt that with a minimal OS 9.2.2 install. I turned off every OS 9 clients file sharing (55). I updated over 40 location manager control panels so file sharing would stay off. Then I logged them all in, mostly OS 9.2.2 clients, some with Retro 5 clients, some with Retro 4. Others include a Win98 & a Win2000 Pro, an OS X 10.1.3 mail server and a OS X 10.1.3 file server, and a few OS X clients. I am now halfway through all the clients. This is the furthest I have gotten since almost 2 weeks ago. And the first time my servers have had tape backup.

 

 

 

I'm feeling better. I am still furious at Dantz for the trouble I have gone through because of this. I didn't use any of the 5.0 previews in real life because I didn't want to risk a beta. Now I know why I didn't want to deal with a beta. The one thing I can say on the plus side is my speeds are probably 3-4 times faster than under Retro 4.3. I don't know how much can be attributed to the new box.

 

 

 

Hopefully a patch will be out soon. If my backups fails at all, you'll hear from me again. If not, I hope everyone out there have good, stable drives and no odd accidents.

Share this post


Link to post
Share on other sites

Greetings,

 

 

 

Dantz has released a minor update to Retrospect Backup version 5.0 that all customers should download and install.

 

 

 

This update fixes a problem that caused all Retrospect Backup 5.0 editions running under Mac OS X to continually increase their memory usage while any LaunchCFMApp process was running. (LaunchCFMApp is a process used in Mac OS X to open Carbon applications.)

 

 

 

This update also fixes a problem that caused Retrospect Desktop, Workgroup, and Server Backup 5.0 editions running under Mac OS 9 to assert failure (with "elem.c-812") when backing up a client AppleShare IP Server or a client computer that has personal file sharing turned on. (This issue does not affect Retrospect Express installations.)

 

 

 

Retrospect Express 5.0 Updater:

 

ftp://ftp.dantz.com/pub/updates/Express_50203_Update.sit

 

 

 

Retrospect Desktop/Workgroup/Server 5.0 Updater:

 

ftp://ftp.dantz.com/pub/updates/Retrospect_50203_Update.sit

 

 

 

Thank you.

 

 

 

Irena Solomon

 

Dantz Tech Support

Share this post


Link to post
Share on other sites
Guest

Thanks for the update. However, judging from many of the postings I have read on this subject, I believe many would disagree with your assessment of this being a minor update.

 

 

 

Anyway, thanks again for the update. I'm sure that fixing the problem was just as nervewracking for you as waiting for it was for us.

Share this post


Link to post
Share on other sites

THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU! THANK YOU!

Share this post


Link to post
Share on other sites

I just installed the update, and ran it. It appears to work perfectly. I will know for sure when it runs tonight. But, it did not give me an internal consistency error and it did not crash my server. This is using Retrospect on an OS 9 machine connecting to an AppleshareIP server.

 

 

 

Jeff

Share this post


Link to post
Share on other sites

So, now, using the new version, you are right, no more 812 errors. However, now I'm getting elem.c-817 errors everytime I try and backup an OS X client from retro 5 server under OS 9.2.2:

 

 

 

Internal consistency check failed:

 

Assertion check at "elem.c-817"

 

4/9/2002 1:02:57 PM: Execution incomplete.

 

 

 

Not too impressive Dantz, should we now rename this thread 'Elem.c-817 Workarounds'?

Share this post


Link to post
Share on other sites

I am so amazingly worn out. I've been putting out fires all day. And now, guess what. No, no, go ahead, guess?

 

 

 

Yup, my ASIP fileserver crashed during backup.

 

 

 

Again.

 

 

 

And this is with the 'minor' update. Maybe a major update is worth releasing?

Share this post


Link to post
Share on other sites

Someone kill me.

 

 

 

I'm having the same errors that BiG is having... elem.c-817 instead of elem.c-812.

 

 

 

 

 

Sigh.

Share this post


Link to post
Share on other sites

It was my Appleshare server that crashed it too. (OS 8.6 + Appleshare IP 6.2 and OS 9.1 + Appleshare IP 6.3).

 

 

 

Haven't seen it go on the OS X server yet.

Share this post


Link to post
Share on other sites

strangely enough, after running through one of the two Mac backup sets perfectly, i've started getting Elem.c-812 errors again.

 

 

 

so far it has yet to get through more than a machine or two before puking. weird part is it backed up 11 Macs in the other script without a hitch. i have no idea anymore what in the world is going on with this program. it seems like every time things are finally squared away something else crops up.

 

 

 

anyone else coming across this? i recreated the backup set and that didn't make any difference on the set that crashes. i'll run through it again after i get other sets backed up. it's been a week or so since they've been backed up, so i'm a little nervrous about getting a full copy of the other sets before i play around with the one that's not working.

 

 

 

anyone else still getting Elem.c-812 errors?

Share this post


Link to post
Share on other sites

Mayoff & Dantz -

 

 

 

Here is the log from an elem.c-812 error that occured when backing up a freshly built up Mac OS X file server running 10.1.3 server and retro client 5:

 

 

 

" Retrospect Problem Report

 

date: 4/14/2002 10:07 PM

 

version: 5.0.203

 

 

 

Internal consistency check failed:

 

Assertion check at "elem.c-812"

 

 

 

Stack Crawl...

 

DATA_0000 +4cc44

 

DATA_0000 +f0214

 

DATA_0000 +2962c

 

DATA_0000 +1ad2c

 

DATA_0000 +5f090

 

DATA_0000 +544c8

 

DATA_0000 +5f288

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f2ac

 

DATA_0000 +5f63c

 

DATA_0000 +63bdc

 

DATA_0000 +2fe60

 

DATA_0000 +1f288c

 

DATA_0000 +1f39a4

 

DATA_0000 +55c74

 

DATA_0000 +55e98

 

DATA_0000 +1f3d14

 

DATA_0000 +2fe60

 

DATA_0000 +ca0c4

 

DATA_0000 +2fe60

 

DATA_0000 +cbc80

 

DATA_0000 +2fe60

 

DATA_0000 +d3244

 

DATA_0000 +55c74

 

DATA_0000 +55e98

 

DATA_0000 +55c74

 

DATA_0000 +55e98

 

DATA_0000 +d3308

 

DATA_0000 +55c74

 

DATA_0000 +55e98

 

DATA_0000 +29868

 

DATA_0000 +55c74

 

DATA_0000 +55e98

 

DATA_0000 +29968

 

DATA_0000 +29ab4

 

 

 

---"

 

 

 

Any advice?

Share this post


Link to post
Share on other sites

Got the same error again this morning - same OS X server, new backup script with all new retro preferences. Any ideas? This thread seems to have gone dormant, but problems persist!

Share this post


Link to post
Share on other sites

Is this happening the same way it was happening for everyone before?

 

Does it only happen to OS 9 clients with FileSharing on?

 

 

 

I know the problem with 5.0.201 was with the RetroRun process.

 

And I _think_ that the old process is replaced with the new process when the new version of the application package is run.

 

 

 

But, to be sure, (if the .201 was running on this machine previously) I'd suggest:

 

 

 

- killing the RetroRun process

 

- trashing /Library/StartupItems/Retrorun

 

- trashing /Library/Preferences/LaunchRetroHlper

 

- restarting Retrospect and seeing if it happens again.

 

 

 

Oh, and if it does? Post exact, step by step details of how it happens!

 

 

 

Dave

 

 

 

 

Share this post


Link to post
Share on other sites

Hate to say it but....

 

 

 

server machine is OS 9.2.2, with version 5.0.203 of retro. Client is OS X server 10.1.3 that *never* had a beta client installed on it. I have rebuilt both machines and set them up from scratch using clean preferences, et. all, twice now. Still reports the error. Mayoff has been pretty responsive and I think this is a new problem rather than a re-occurance of the old.

 

 

 

Thanks though <:-|

 

 

 

 

Share this post


Link to post
Share on other sites

Hello,

 

I got the same error and found it had only to do with one client. That client was running Fileguard 4.1 protection. As soon as I turned off Fileguard it backed up fine with Retrospect 5.O The client was running OS 9.2.2 and file sharing was on. I have since turned it off.

Share this post


Link to post
Share on other sites

I know Apple & Dantz are working on a resolution, and I appreciate that, but oh, still getting elem.c-812 errors. Sooooooo tiring, sooooo scary and soooo old!

 

 

 

Maybe in the next update.....

Share this post


Link to post
Share on other sites

BiG writes:

 

I'm getting elem.c-817 errors everytime I try and backup an OS X client from retro 5 server under OS 9.2.2

 

 

 

I've looked through your posts, but I can't find a detailed description of your setup.

 

 

 

I understand the client is a fresh OS XS install, but what is the exact hardware?

 

I understand the application is running under OS 9.2.2, but what is the exact hardware?

 

 

 

I have the following configuration and have never seen any of these errors:

 

 

 

Application:

 

iMac 600Mhz slot loading (CDRW) (smoke)

 

Mac OS 9.2

 

Retrospect 5.0.203

 

No devices, backing up to File Backup on internal IDE drive

 

 

 

Client:

 

G4/733

 

Mac OS X 10.1.4 5Q145

 

Retrospect client 5.0.528

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Dave -

 

 

 

Thanks for the piqued interest.....My config is:

 

 

 

Backup Server -

 

Retrospect Server v.5.0.203 (tried 205, went back as I couldn't back my server up as a mounted volume even anymore)

 

Power Mac G3/266

 

384MB RAM - 200MB assigned to Retrospect

 

Asante 10/100 PCI card

 

Adaptec PowerDomain 29160 SCSI card (supported under OS 9.x)

 

Lacie 35/70GB AIT drive (SONY mechanism)

 

 

 

Servers -

 

ASIP 6.3 Print server/Filemaker 4.1 server (OS 9.1, client 5)

 

OS X 10.1.4 (server edition) mail server (client 5, mirrored 40GB drives)

 

OS X 10.1.4 (server edition) file server (client 5, 48GB IBM Deskstar)

 

 

 

Clients-

 

70% OS 9.2 (100% with 5 client)

 

20% OS X 10.1.4 (all with 5 client)

 

10% Windows boxes (WinMe+2k, all with 5.0 client)

 

 

 

I am now successfully backing up everything *except* my OS X file server. Under 203 it crashed upon completing the file scan, under 205 it crashed midway through the file scan (by crash, I generally mean elem.c-812 error). I've also never ever successfully backed up my own laptop, a G4 550 w/OS X 10.1.4. I can't pinpoint when, as it seems at random, but it always produces a elem.c-812 error. I have done a couple clean installs to both the server and retrospect machine. My machine has had a fresh install of the client, all previous versions removed through the terminal.

 

 

 

That's about it. Currently I am backing up my file server as a mounted version. My only other wierd problem is that I have consistent execution errors on everyones MS Entourage mail Database. That is relatively minor, which is why I haven't fussed over it. It is the server which truly concerns me.

 

 

 

alex

Share this post


Link to post
Share on other sites

I am now successfully backing up everything *except* my OS X file server. Under 203 it crashed upon completing the file scan, under 205 it crashed midway through the file scan (by crash, I generally mean elem.c-812 error)

 

 

 

Cool, more data points are always better then less.

 

 

 

By your description the crash/quit/assert always happens before any files are copied. Can you try and set up a backup to a File Set instead of to any Device? This would take the interaction between Retrosepct and the backup device out of the equation.

 

 

 

If the crash continues to File Sets, try defining the root level directories as Volumes (Retrospect will see all of them, even /private) and back them up one at a time. Perhaps there are specific files that are causing this, and knowing if you could successfully scan (for example) the default /private, /usr/, /bin etc directories might go a long way towards finding the culprit(s).

 

 

 

Dave

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  

×