Consistency check failed: Assertion check at "elem.c-923"

[Guest]

I have a G3 iBook, Pismo G3 Powerbook, and G4 Powermac all running 10.4.4.

Retrospect 6.1.126 and clients version 6.1.107

Backing up to external Firewire hard drive that has 2 partitions. I'm using 1 of them for the backups (77 GB, 50 GB used, 27 GB available)

 

I've searched the forum and the KB and don't find a reference to this error. I did find Tech Note 307 that talks about internal consistency checks, but thus far it hasn't clued me in to identifying and fixing the problem.

 

The G4 is the normal backup machine and has the FW drive attached. Backups of the clients started failing due to a catalog error:

Catalog out of sync with backup set “Firewire Backup [001]”.

 

I attempted to rebuild the catalog.

+ Executing Recatalog at 1/16/2006 2:25 PM

To backup set Firewire Backup [001]…

Internal consistency check failed:

Assertion check at "elem.c-923"

 

and received the error.

 

I tried rebuidling a couple of times, same results. In between I would reboot the G4 as the Tech Note suggests.

 

So, I moved the FW HD to my Powerbook, and ran Retrospect there to rebuild the catalog. Same result.

 

I ran a verify of the backup set:

+ Executing Verify at 1/16/2006 2:53 PM

To backup set Firewire Backup [001]…

1/17/2006 12:22:40 AM: Execution completed successfully.

Completed: 499099 files, 49.8 GB

Performance: 89.3 MB/minute

Duration: 09:29:34

 

[that takes a LONG time to do]

 

and then attempted another recatalog:

+ Executing Recatalog at 1/17/2006 7:14 AM

To backup set Firewire Backup [001]…

Internal consistency check failed:

Assertion check at "elem.c-923"

1/17/2006 10:06:11 AM: Execution incomplete.

Completed: 757 files, 3.3 GB

Performance: 19.1 MB/minute

Duration: 02:51:43

Quit at 1/17/2006 10:06 AM

 

 

What next? Do I need to trash the backup set and start over? I don't want to lose this, as there are actually some files I need/want off here.

[waltr]

hi hinsch,

 

i was reading yesterday on macintouch.com that some readers are reporting "noise" on their firewire channels after upgrading to 10.4.4. there are also reports that USB devices can cause kernel panics after the upgrade.

 

there may have been some new feature in 10.4.4 that you desperately need at your site, but i always wait until others have suffered through the bugs in apples latest release before i do an upgrade of this sort. you can check out the report here:

 

http://www.macfixit.com/index.php?date=2006-01-17

 

look around 3/4 of the way down the page.

 

i assume that this was all working fine under 10.4.3. you may want to try and downgrade one of the machines to test if it works better for you. good luck.

[rotabene]

I,too!

 

Internal consistency check failed:

Assertion check at "elem.c-923"

 

My config:

PowerMac G4 with MacOSX 10.3.9 Server

Retrospect 6.1.126

Driver Update 6.1.2.102

 

SCSI-Card:

Atto ExpressPCI UL3S

Driver 3.2.0

Flash 1.6.6f0

 

Driver:

Tandberg SDLT 320

 

In December I changed my SCSI card from an Adaptec 29160 to a ATTO UL3S. I also did an upgrade

from Retrospect 6.0 to 6.1.

 

Since this time I get the error permanently when I do a backup. Mostly it happens when comparing.

 

I tried everything EMC support told to me.

 

- Fresh install of Retrospect.

- Test backup to a new Backup-Set

- Changed SCSI-Cables

 

Now I did a downgrade to 6.0 and try a test backup because I think it is a bug in Retrospect 6.1.

Just found this thread and thought I should post my problem.

 

I called support, paid for assistance - got no info - they told me that they don't know

this problem and then finding a thread in the Dantz forum...

 

Does Dantz sometimes read their own forums?

 

Ok but back to the problem has anybody a solution or any ideas?

 

Thx

Det

[Guest]

Quote:

---

hi hinsch,

i assume that this was all working fine under 10.4.3. you may want to try and downgrade one of the machines to test if it works better for you. good luck.

 

---

 

How does a person go about a "downgrade" of the OS without reinstalling and only upgrading to the level wanted since I don't have a working backup to restore from? I haven't been able to find any references on the web about how to go back to 10.4.3.

[natew]

Det,

 

At what point in the backup does the error occur? During the scan before data is copied? During matching? When data is being copied?

 

Does it happen regardless of what source disk you are backing up?

 

Thanks

nate

[rotabene]

The error occurs on the end of the backup when the compare of the last volume is nearly finished or maybe it is almost finished and retrospect does something with the backup set file. If I do a backup of local volumes the errro sometimes does not occur. If I do a backup of a remote Machine the error always occurs.

 

Thanks

Det

[rotabene]

Test Backup with Retrospect 6.0 finished. I don't get the error, retrospect simply crashes! Crash always happens when it is backing up a MacOSX Server 10.3.9 with Retrospect client 6.1.107. This client has two volumes: system and daten. System is backed up and compared successfully. Then while backing up volume daten retrospect is quitting.

In the Report section both volumes then show up as not backed up.

 

Det

[CallMeDave]

Please don't dross-post the same problem in different places; it makes the process of trying to help you more difficult.

 

Dave

[frehator]

I´m experiencing the same problem, unfortunately not with redundant backuo data, but with archived data, which is no longer available on any other medium. When I try to rebuild the catalog file from media, the applications quits with Assertion check at "elem.c-923". I tried different macs, different scsi hbas and even different AIT Drives. no dice.

Is there any hint to get the data back from the tapes??

 

eckart

[CallMeDave]

Quote:

---

Is there any hint to get the data back from the tapes??

 

---

 

I'd say that with the one-way communication capabilites available in on-line message boards, the possibility of anyone helping with the tiny amount of data you've provided is pretty much nil.

 

However, if you post a complete description, including all hardware and software versions, drivers, etc, the history of this hardware and software, at what point the crash occurs, etc, it would certainly help others to help you.

 

Dave

[larburke]

System:

 

- G5 dual 2Ghz/250Mb

- Western Digital 160Gb external USB2

- OS X 10.4.5

- Retrospect 6.1.126

 

- Backing up to LaCie (Sony SDT-9000) DDS3 DAT Tape (SCSI to Firewire bridge)

 

Getting Assert error:

"elem.c 923"

 

Started occurring during catalogue rebuild, but now it occurs immediately when I attempt to search a catalogue.

 

I've done everything I can think of – replaced Firewire cables, replaced the firewire bridge, reinstalled Retrospect, and tried to rebuild catalogues.

 

ANY IDEAS??? WHERE DO I TURN??

Larry

[CallMeDave]

>- Backing up to LaCie (Sony SDT-9000) DDS3 DAT Tape (SCSI to Firewire bridge)

 

What exactly is this?

 

Is this a SCSI tape drive that's connected to a third party SCSI<->FW adapter of some sort?

 

Folks on this board were trying such things in the early OS X/Retrospect 5.0 days (like the SCSIBee); Dantz posted here that those devices were unsupported.

[larburke]

Hey Dave,

 

It's not a third party device. These drives were advertised as “firewire” devices, but actually they are a SCSI Tape Drive that came bundled with a small adaptor which went from SCSI to firewire. That box had some problems, so I've replaced it with a new adaptor which seems to be working fine (Retrospect recognizes the drive under the “devices” window).

 

The troubles seem to have begun with the installation of OS X 10.4.4 and/or the latest version of Retrospect which is the only version compatible with this version of Tiger.

 

Any thoughts?

 

Larry

[CallMeDave]

> Any thoughts?

 

I think that OS X is very particular about SCSI host adapters, and your new adapter (which, for the life of me, I can't understand why you don't document its make/model) is showing to be unsupported by Retrospect in the version of the OS that you are using.

[larburke]

Hey Dave,

 

Sorry about that. Thanks for your patience. I'm a graphic designer and longtime Mac user (first Mac: Mac SE30 1986), but this one is waay out of my depth.

 

I'll tell you what I can. Anything else, just ask. :-)

 

When Retrospect scans the firewire bus, under DEVICE STATUS, it comes up with:

 

ID: Firewire-A

Vendor: SONY

Product: SDT-9000

Version: 0601

Driver: SONY DAT DDS-DC (5.03)

 

The replacement adaptor is a

Ratoc Systems FR1SX FireWire-UltraSCSI Converter

and is described here:

http://web1.ratocsystems.com/english/products/subpages/firerex1.html

 

the list of compatible devices is here:

http://web1.ratocsystems.com/english/support/Compatible/fr1sxlistmac.html

 

The replacement adaptor shows up in the SYSTEM PROFILER as follows:

 

FireWire Bus:

Maximum Speed: Up to 800 Mb/sec

IEEE1394 - SCSI-3:

 

Manufacturer: RATOC Systems,Inc.

Model: 0x0

GUID: 0xC0D00000FBEA27

Maximum Speed: Up to 400 Mb/sec

Connection Speed: Up to 400 Mb/sec

Sub-units:

IEEE1394 - SCSI-3 Unit:

Unit Software Version: 0x10483

Unit Spec ID: 0x609E

Firmware Revision: 0x10133

Product Revision Level: 0601

Sub-units:

IEEE1394 - SCSI-3 SBP-LUN:

 

I hope this tells you what you need to know, but if not, please let me know what info you need and I'll try to find it.

 

Many thanks,

Larry

[CallMeDave]

I see on the Ratoc website it claimes:

 

Mac

Certified Applications

DANTZ Retrospect 5 or later for backup devices

 

I don't know how they're certifying this, but Dantz certainly never gave similar official approval to this device either when 5.0 shipped (when Dantz tech goddess Irena noted here on the Forum that SCSI adapters were unsupported) or since.

 

So you're in the grey area of unsupported hardware; if it works, enjoy. If it doesn't, you need to change to something that does.

 

This KnowledgeBase article gives some background to SCSI issues on OS X; in short it makes clear that SCSI support is the responsibility of the hardware and operating system; Retrospect simply issues the standard commands.

 

- Have you contacted Ratoc to report the problem?

 

Dave

[marcbenitez]

Try forgeting the client in the client/network box, search, re-establish client, select volume. close all boxes and start your backup server. It worked for me. Mac powerbook G4 OSX 10.4.5 as the server running Retrospect 6.1 Desktop. Clients PC laptop Windows XP OS second client Mac Powerbook G4 Mac OSX 10.4.4.

 

Marc

[rdzman]

In my case, this error was caused by a client (Windows) whose clock was way out of sync with the clock on the backup server. Fixing the client's clock and restarting Retrospect on the backup server cleared up this repeatable crash for me.

[macparamedic]

I'm having the same error/problem.

 

This is the screen error -

Internal consistency check failed:

Assertion check at "elem.c-923"

 

The error message is reported almost immediately when the regular or recycle backup script is invoked to run.

 

The only option is to Quit.

 

The same error is reported in the logs.

 

The backup server script runs fine. It writes to the same backup sets and media as the two scripts that fail.

 

relevant details-

 

Retrospect 6.1.230

Retrospect Driver Update, version 6.1.15.101

iMac G4

800 MHz

768 MB RAM

OS 10.4.11

 

Two external hard drives for alternating backups (set 1, set 2)

The drives are identical WD My Book HD's 500 GB capacity

 

They are connected to the Mac's built-in firewire bus.

 

The clients are Macs and PC's.

The client versions are all over the place

(PC)

6.5.136

6.5.140

7.5.116

7.6.106

 

(Mac)

6.1.130

 

What I have done -

restarted the computers

tried both external drives

verified disks (internal and external) using the Mac Disk Utility

repaired permissions on internal drive

re-cataloged one of the two backup sets (successful)

synchronized the clocks on all the clients

 

Before I go through the hassle of erasing the drives and re-create the scripts, I thought to ask again here if there are any other suggestions for things to try.

 

If I do manage to solve the problem, I will report back to the forum.

 

thanks-

[twickland]

Assert errors can also be caused by a corrupt Retro.Config file (located at /Library/Preferences/Retrospect). You might try this: With Retrospect not running, drag Retro.Config to the desktop. (Do this rather than trash the file, so that you can drag it back if it turns out not to be at fault.) Then relaunch Retrospect, which will force creation of a clean default Retro.Config, and see if you can get through a test backup without encountering the assert error.

 

Retro.Config contains all your scripts and lists, so if it does turn out to be corrupt (and if you don't have a good backup copy), you will need to recreate all of those items from scratch. At least that would be easier than reformatting the whole drive.

[macparamedic]

Thanks for the suggestion.

 

Before I do what you suggested, which would require re-creation of the (rather complicated) scripts, I should report that I successfully ran a test backup (new script) of one of the clients to an existing backup set. So, it might seem that the overall program prefs are OK.

 

Moreover, at least one of the script(s) in question does sporadically work. After several days of not working with the above error, it worked once and then failed again.

 

It's confusing.

 

I did duplicate (just copied) one of the scripts and it also failed with the reported error.

 

Thanks again for the suggestion.

[macparamedic]

OK, I finally deleted the Retro.config file as suggested and it seems to have solved the problem.

 

It was strange, because the scripts would sometimes work and then fail with the Assertion check error mentioned.

 

The laptop scripts would work fine and I was able to make a new test backup that worked as well.

 

I deleted one client from a problem script and it worked for a while, then failed later in the script with the same error.

 

Eventually, I couldn't even make a test backup run.

 

So I deleted the config file, re-entered my serial number etc and re-created the client setup from scratch. It seems to be working.

 

Thanks again for your help with this problem. It is working now, albeit after a lot of work to reconstruct the clients and scripts etc.

 

I was able to use the existing backup sets, though. I didn't erase the backup volumes.

 

I also modified my backup scripts so that I am backing up the /Library/Preferences/Retrospect folder, so if this happens again, I will be able to go back to a previous config file.