Jump to content

Internal Consistency Check Failed


Recommended Posts

I just upgraded to 5.0 on Mac OS 9. When I get through a few of the clients Retrospect will throw a dialog saying:

 

 

 

Internal consistency check failed:

 

Assertion check "elem.c-812"

 

 

 

My only option is to click "Quit" in that dialog and Retrospect quits.

 

 

 

If I try again it seems to get further but I still get the error.

 

 

 

Any idea what is going on? Please help!

Link to comment
Share on other sites

Does this happen all the time? Is it reporducible? Can you narrow it down to a particular client? What version of the client software are the clients running? What operating system?

 

 

 

Retrospect does internal consistency checks to ensure internal operations are fine. In this case it most likely detected that an internal file in use by Retrospect has been corrupted. Often the context of the error is most important. If you get the error during backup or restore, it is accessing the catalog file for the backup set and may indicate that that file is corrupt. If you are merely clicking around in Retrospect or launching the program and you produce an error, it may be corrupt preferences. The solution to a corrupt catalog is to rebuild it from the media using Tools>Repair>Recreate from (tape, disk, etc.). But before you do that, you might want to verify it truly is a problem with your catalog file by doing the test below:

 

 

 

The catalog file is the file in your Retrospect folder (that's where it's usually kept) that has the same name as your backup set. If you pretend to do an Immediate > Restore > Search for files and folders, and apply a search criteria that reads "File name does contain xjfe2dk1" (a gibberish, non-existent file), it will search for ALL files on the backup set catalog from A to Z. If you get the same error during this search, it indicates corruption to the catalog and you need either to rebuild it from the media, do a Full Backup to this backup set, or create a new backup set for use. To rebuild, you go to Tools> Repair> Recreate from....

 

 

 

If it is not the catalog file at all, you need to go to your Preferences folder, open the Retrospect folder and either trash or hide in another folder, the "Retro.Config (5.x)" file and/or the "Retro.Icons (5.x)" file. Relaunching Retrospect will create a fresh set of these files. The side-effect is that you lose your scripts and logged in clients. You'll need to rewrite your scripts and relog clients if you indeed need to trash these files. If their replacements don't improve the situation, you might as well reinstitute the original files into the Retrospect preferences folder to regain your scripts and clients.

 

 

 

If you complete this troubleshooting, are you able to pinpoint the problem?

 

 

 

 

Link to comment
Share on other sites

I have got the same problem, after I upgraded from 4.3 to 5.0 workgroup server. This seems to be client-related and occurs in a backup script, after updating folders en before matching previous sessions.

 

It seems to help if the client-computer is restarted.

 

 

 

Well, it is quite annoying

Link to comment
Share on other sites

Thanks for your post. I'd like to get a bit more information from you so we can look into this. For testing purposes, you can use the ~No Files selector so that you don't need to go through full backups.

 

 

 

What OS is the backup computer running? What version of Retrospect?

 

 

 

Did you have previous versions of 5.0 (the preview version) installed?

 

 

 

Did you update from 4.3, or did you start with fresh preferences?

 

 

 

Does this happen with immediate backups as well?

 

 

 

Does it happen with all clients?

 

 

 

If not, how many clients are you seeing this on?

 

 

 

What operating system and version of the client software are they running?

 

 

 

Does if happen if you try a new backup set?

 

 

 

Please feel free to post this or send a private message to me within the forum.

 

 

 

Thanks,

 

 

 

Irena

Link to comment
Share on other sites

I too have this problem. On Tuesday it tried failed to back up even one client on the netowrk. Last night it was able to back up one network client, and this time I saved the log, here it is (names have been changed to protect the innocent). The first backup is a local drive.

 

 

 

 

 

+ Normal backup using Documents Only ALL/Even at 3/27/2002 8:00 PM

 

To backup set Net Backup - C…

 

 

 

- 3/27/2002 8:00:22 PM: Copying xxxxx HD…

 

3/27/2002 8:03:50 PM: Execution completed successfully.

 

Completed: 12 files, 68.0 MB

 

Performance: 44.3 MB/minute

 

Duration: 00:03:28 (00:01:56 idle/loading/preparing)

 

 

 

3/27/2002 8:03:59 PM: Connected to xxxx xxxx

 

 

 

- 3/27/2002 8:03:59 PM: Copying xxx HD on xxxx xxxx…

 

3/27/2002 8:23:03 PM: Execution completed successfully.

 

Completed: 33 files, 208.7 MB

 

Performance: 13.0 MB/minute

 

Duration: 00:19:04 (00:03:06 idle/loading/preparing)

 

 

 

3/27/2002 8:23:16 PM: Connected to xxx xxxx

 

 

 

- 3/27/2002 8:23:16 PM: Copying xxx Disk on xxx xxxx…

 

 

 

! 3/28/2002 10:05:02 AM: System clock and tick timer appear inconsistent, code 2.

 

Dates, times and statistics may be incorrect.

 

Internal consistency check failed:

 

Assertion check at "elem.c-812"

 

3/27/2002 8:23:16 PM: Execution incomplete.

 

 

 

 

 

This is the same error I received the first time. My (the backup) Computer is a Beige G3/266 with 192 Megs of RAM (110 assigned to Retrospect) running OS 9.1. The Tape Drive is a LaCie DDS 4 Dat drive attached to a Inito Miles 9100UW, there are no other devices attached to the Miles Card. The two computers referenced above are Beige G3/233's with 128 Megs of RAM running OS 9.1 and Remote Client 4.2A. I just tried an immediate backup of a different client running Remote 4.3 and OS 9.1 and had no problems. I'm using Retrospect 5.0 Workgroup with settings from my previous 4.3 instillation.

 

 

 

I saw a mention on MacFixIt that Retrospect Desktop Backup 5.0 requires 5.0 Remote Clients, is that true, and if so does this apply to Workgroup? Here is the item directly from MacFixIt:

 

 

 

"Retrospect 5 only woks with 5? Matt Smyj was told that Retrospect 5.0 Desktop Backup for OS 9 requires that you use Retrospect 5.0 clients-only."

 

 

 

--Joshua.

Link to comment
Share on other sites

I have some more information after doing some more tests.

 

 

 

While running in the previous messages configuration, I ran a newly created script (the old ones where still there) and Backup Set from the Run menu on 4 Remote Clients (3 are 5.0 and 1 is 4.2A). The first time I ran on three of the four machines, but quit with the same Assertion check at "elem.c-812" error (it failed on a 5.0 client) when it was updating Folder Privileges. I relaunched Retrospect and tried the same script from the Run Menu and this time it failed at the same point, but with the First Client. I was able to repeat this several times, the only difference being I rearranged the order in which the Clients are accessed. It dawned on me that it might be a good idea to restart between Assertion check errors. Even with a restart between Assertion check errors the Backup attempt would always fail when it was updating Folder Privileges. I even tried an immediate backup of a network client with the same settings that I had used in the Script previously, and that failed in the same place. I decided that I would update my Mac to Mac OS 9.2.2, since I was looking for an excuse to do that anyway. Well, after updating to 9.2.2 I tried again with the same Remote Clients and Scripts, and everything worked fine! I'll be running a full backup over this weekend and I will report what happens.

 

 

 

--Joshua.

Link to comment
Share on other sites

I am having this problem also. So far, I cannot get more than partway through a backup script before this happens. I was running 4.3 on a 7100/66 with two APS Hyperdat III with about 20 or so clients with no problem. I was motivated to upgrade because the beta X client was expiring. After the upgrade, I got this error. A newer machine had become available, a 7200/120 so I installed a fresh system 9.1 with the latest carbonlib, etc. (ran software update until it reported no update needed), installed Retropsect 5.0 for Server, installed new clients, made new scripts. It will run for part of backup but never will execute the entire script.

 

 

 

I gather this configuration just won't work with Retro 5 until a fix is available.

 

 

 

Should I reinstall 4.3, reinstall the clients (they are scattered in various buildings around the campus...it will be quite a chore) and wait for a solution? Should I sit tight in hopes the fix will be available in a day or two and advise my clients to do their own backups in the meantime? Or should we write this one off, go back to 4.3, and get a refund for 5.0?

 

 

 

The basic question is when could we expect a fix???

Link to comment
Share on other sites

I too am having the problem. The solution in the meantime is to turn off file sharing on machines running 9.x....its a pain in a large organization but it works. It backup's OS X clients fine even if file sharing is enabled and it does backup OS X server fine as well. It is best to run server on a 9.X machine as if you run the server on OS X there is a memory leak problem as well. Who knows when a fix will be available. Hopefully there are not alot of other yet to be discovered bugs......

 

 

 

Peter Haase

 

Systems & Network Manager

 

Los Alamos National Laboratory

Link to comment
Share on other sites

I've turned off file sharing on several machines, including my own desktop (a G4/400 running 9.2.2), and I have had the dreaded error of death even while it was working on machines with file sharing off.

 

 

 

I'm beginning to feel good about charging the server upgrade ($350) to a credit card. At least if this does not get sorted out soon, we can dispute the charge.

Link to comment
Share on other sites

Hi all,

 

I'm having the problem of the Internal Consistency Check Failure (assertion "elem.c-812") and was wondering about possible work arounds while we wait for Dantz to address the problem.

 

 

 

The suggested workarounds (in another thread on this bulletin board) have been to disable personal file sharing on the client machines and increase the Retrospect memory allocation to at least 50MB.

 

 

 

(BTW it doesn't seen to matter if the client is using TCP/IP or AppleTalk for filesharing. It is also not universal, ie all my clients have AppleTalk active but only a subset cause Retrospect 5 to fail).

 

 

 

Turning off file sharing is not really an option here because people depend on it every day... and changing the memory allocation doesn't seem to make any difference for me.

 

 

 

A couple of alternative workarounds that I have thought of include:-

 

 

 

* An applescript to turn off filesharing... can this be done? could it be triggered remotely? I would love to be able to run a single AppleScript on my machine each night that we go through all the clients and turn off file sharing. If people need it then they can turn it on themselves the next morning.

 

 

 

* Can I run Retrospect 4.3 and 5.0 in parallel on the same machine? ie I would setup a script in Retro4.30 to backup all the OS 9 clients (which cause the crash) and then a Retro5 script to backup the couple of OS X clients over lunch (or whenever...)? Would this work? Will I have to manually launch one or other of the applications? What problems might I encouter if I write to the same backup sets with both versions?

 

 

 

Any other suggestions would be most appreciated...

 

 

 

Adrian

 

 

 

PS Does anyone know Retrospect 5.0 crashes in the same way when run under OS X?

 

 

 

 

 

backup machine - G3/266, 384MB RAM, Sony SDT-S11000 (DDS-4), Adaptec 29160N, 15 clients (4 of which are OS X).

Link to comment
Share on other sites

I too started encountering the assertion errors, although I was getting "task.c 402" as the footnote. I found what appears to be a workaround for the moment -- don't know if this will work for anyone else, but I tried it on two different Macs which are running OS 9.2.2 and Retrospect 5 and it backed up and shut down fine (tried it twice on one Mac, once on the other).

 

 

 

I was using the Retrospect Event Handler to have Entourage email me the backup log before shutting down at night. Removing the REH from the equation seems to have done the trick. True, I don't get an email log right now, but the Mac backs up and shuts down fine.

 

 

 

Hoping this helps someone out there...

Link to comment
Share on other sites

I have implemented a solution to the "internal consistency check failed assertion check at elem.c-812" problem. After trying all the suggestions mentioned in this forum and some others, starting over with a completely new backup machine, reformatting the disk, installing a new OS, etc. Everything works just fine. I am back to Retrospect 4.3 and everything is operating very well. Fortunately, the 5.0 remote clients seem to work fine with the 4.3 server. The only catch is that my MacX clients are not being backed up which is the reason we upgraded in the first place.

 

 

 

Thank god we paid by credit card.

Link to comment
Share on other sites

Several days ago I tried e-mail to customer service asking about how to get a refund for 5.0 since we are now back to 4.3. No response. That seems to leave a charge dispute as the only mechanism.

 

 

 

It would be very helpful if Dantz could communicate *something* to us. Just a hint of whether this is looking like days, weeks, months, years or what to solve this. We've been put though much effort to get back into the business of performing backups. Since there is no indication otherwise, I'm assuming this could be weeks rather than days to get a fix.

Link to comment
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

Link to comment
Share on other sites

After having encountered this problem trying to upgrade from 4.3 to 5.0, I migrated to a new server machine (a 7200/120 from a 7100/66), installed a fresh system, and reinstalled 4.3. When the 5.0.203 update became available yesterday, I applied the 5.0 upgrade to the new 4.3 then immediately appled the 5.0.203 update.

 

 

 

So far, so good. Everything seems to work except the remote clients that still may be using Appletalk. I expect that after I install new 5.0 clients, all will be well.

 

 

 

It's been real. But, now it does seem to work and the upgrade from 4.3 to 5.0.203 would appear to be as painless and uneventful as previous Retrospect upgrades were. The 4.3 to 5.0 step was a nightmare and I hope others will know about this fix so they can avoid the pain and suffering.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...