How to resolve persistent error in dsrepair?
Paulo R Oliveira
Migrating NW51sp7 to NW65sp2 with migration wizard7.1 fails on restoring
eDIR/NDS - step 3.
Only error in NDS on source server is "ERROR: Illegal replica number 0 is
reissued" and a search of support states it's "cosmetic" error no
consequences... Help, is it because of this that the migration failed?
I've attached the dsrepair.log for your review...
thanks
Paul
/***************************************************************************
*/
NetWare 1602.00 Directory Services Repair 10550.76, DS 8.85c
Log file for server ".HAL.BBE" in tree "EACOTT"
** Automated Repair Mode **
Repairing Local Database
Start: Sunday, August 15, 2004 10:42:47 am Local Time
** All disk amounts are approximations **
->Current available disk space: 1492 MB
->DSRepair may need to use: 2 MB
->Disk space remaining after operation: 1492 MB
Physical Check
Creating Temporary Files
Repair Trees - Scan Values
Repair Trees - Sorting Values
Repair Trees - Scan Entries
Repair Trees - Sorting Entries
Repair Trees - Check Values
Repair Trees - Check Entries
Total Objects in Database: 834
Total Objects in Schema : 733
Total External References: 1
Total Objects in Replicas: 90
Schema Check
Repairing objects in a replica
Start: Sunday, August 15, 2004 10:42:53 am Local Time
[1 of 1] Master : T=EACOTT
ERROR: Illegal replica number 0 is reissued
Object ID: 0000805A, DN: T=EACOTT
Total Objects = 90, UNKNOWN class objects = 0, Total Values = 12041
Checking local references
Start: Sunday, August 15, 2004 10:42:54 am Local Time
Repairing single object:
Object ID: 00008058, [Pseudo Server]
Total Objects = 1, UNKNOWN class objects = 0, Total Values = 9
Temporary DIB set replacing NDS working DIB set.
Checking mail directories
Checking stream syntax files
Repair process completed, total errors found = 1
** Automated Repair Mode **
Repairing Server Network Addresses
Start: Sunday, August 15, 2004 10:42:55 am Local Time
****************************************************************
This operation will search IPX, SLP, and DNS tables, if
available, in order to validate network address attributes of
NCP_SERVERS, as well as the referrals on replica objects.
If the information on DNS/DHCP tables or the /etc/hosts file is
incorrect, then we cannot guarantee proper validation of network
addresses, nor replica referral updates. This is particularly true
if the system uses unregistered DHCP addresses or the information
in the HOSTS file is incorrect or outdated
****************************************************************
Checking server: .HAL.BBE
Found a Network Address Property on the server object and through SLP:
Address Type = IPX, data[12] = 366C52AB0000000000010451
Found a Network Address Property on the server object and through SLP:
Address Type = TCP, data[6] = 10.0.0.1:524
Found a Network Address Property on the server object and through SLP:
Address Type = UDP, data[6] = 10.0.0.1:524
Checking server address in Replica ID: 1, .[Root].
** Automated Repair Mode **
Repairing replica ring
Start: Sunday, August 15, 2004 10:43:03 am Local Time
Replica Ring for replica: .[Root].
Remote server's local ID: 0000805C
Remote server's replica root ID: 0000805A
Remote server name is: .HAL.BBE
OK - Authenticated to server
** Automated Repair Mode **
Volume Object and Trustee Check
Start: Sunday, August 15, 2004 10:43:03 am Local Time
Volume: SYS, object ID: 00008081, CN=HAL_SYS.O=BBE.T=EACOTT
Checking trustees on volume: SYS
Volume: ACCOUNTING, object ID: 00008082, CN=HAL_ACCOUNTING.O=BBE.T=EACOTT
Checking trustees on volume: ACCOUNTING
Volume: ESTIMATING, object ID: 00008083, CN=HAL_ESTIMATING.O=BBE.T=EACOTT
Checking trustees on volume: ESTIMATING
Volume: GROUPWISE, object ID: 00008094, CN=HAL_GROUPWISE.O=BBE.T=EACOTT
Checking trustees on volume: GROUPWISE
Volume: PROGRAMS, object ID: 00008084, CN=HAL_PROGRAMS.O=BBE.T=EACOTT
Checking trustees on volume: PROGRAMS
Volume: SPARE, object ID: 00008085, CN=HAL_SPARE.O=BBE.T=EACOTT
Checking trustees on volume: SPARE
Volume: USER, object ID: 00008086, CN=HAL_USER.O=BBE.T=EACOTT
Checking trustees on volume: USER
Volumes checked: 7
** Automated Repair Mode **
Finish: Sunday, August 15, 2004 10:46:38 am Local Time
Total repair time: 0:03:52
Andrew C Taubman
the same time. This will cause user problems while running, so you may
want to schedule it accordingly.
--
Andrew C Taubman
Novell Support Forums Volunteer SysOp
http://support.novell.com/forums
(Sorry, support is not provided via e-mail)
Opinions expressed above are not
necessarily those of Novell Inc.
Paulo R Oliveira
Paul
"Andrew C Taubman" <ataubman...@novell.AndSpamLovesMe.com> wrote in
message news:0dTTc.2944$h07....@prv-forum2.provo.novell.com...
Andrew C Taubman
a dsrepair that locks the database. Try doing a local repair with
Structure and Index check On, and Lock local DB On.
If that doesn't fix it, that's puzzling, but it won't be causing any harm.