Upgrade 389-ds-base from 1.2.2-1.el5 to 1.2.9.9-1.el5. The server refuses to start, the error log complains: [28/Dec/2011:06:24:16 -0600] - nsslapd-subtree-rename-switch is on, while the in stance userRoot is in the DN format. Please run dn2rdn to convert the database format. [28/Dec/2011:06:24:16 -0600] - nsslapd-subtree-rename-switch is on, while the instance NetscapeRoot is in the DN format. Please run dn2rdn to convert the databa se format.[28/Dec/2011:06:24:16 -0600] - start: Failed to start databases, err=-1 Unknown error: -1[28/Dec/2011:06:24:16 -0600] - Failed to start database plugin ldbm database[28/Dec/2011:06:24:16 -0600] - WARNING: ldbm instance userRoot already exists [28/Dec/2011:06:24:16 -0600] - WARNING: ldbm instance NetscapeRoot already exists Discover that dn2rdn is called from setup-ds.pl, so we run "setup-ds.pl -u". No idea why the RPM postinstall script doesn't "do the right thing". We run "setup-ds.pl -u" and it emits thousands of warnings, one for each entry in the database: [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a corrupted dn (syntax value): zzz0107A (id 63863) [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a corrupted dn (syntax value): zzz MS E (id 63864) [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a corrupted dn (syntax value): zzz0111A (id 63865) [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a corrupted dn (syntax value): zzz DR I (id 63866) At the end up the upgrade process, the database is completely empty, all data has been destroyed. The message "skipping an entry with a corrupted dn (syntax value)" is too vague to be useful - it doesn't say what DN, it doesn't say what syntax value, so I'm in the dark as what action to take.
(In reply to comment #0) > Upgrade 389-ds-base from 1.2.2-1.el5 to 1.2.9.9-1.el5. > > The server refuses to start, the error log complains: > > [28/Dec/2011:06:24:16 -0600] - nsslapd-subtree-rename-switch is on, while the > in > stance userRoot is in the DN format. Please run dn2rdn to convert the database > format. > [28/Dec/2011:06:24:16 -0600] - nsslapd-subtree-rename-switch is on, while the > instance NetscapeRoot is in the DN format. Please run dn2rdn to convert the > databa > se format.[28/Dec/2011:06:24:16 -0600] - start: Failed to start databases, > err=-1 Unknown > error: -1[28/Dec/2011:06:24:16 -0600] - Failed to start database plugin ldbm > database[28/Dec/2011:06:24:16 -0600] - WARNING: ldbm instance userRoot already > exists > [28/Dec/2011:06:24:16 -0600] - WARNING: ldbm instance NetscapeRoot already > exists > > Discover that dn2rdn is called from setup-ds.pl, so we run "setup-ds.pl -u". No > idea why the RPM postinstall script doesn't "do the right thing". RPM postinstall does run setup-ds.pl -u > > We run "setup-ds.pl -u" and it emits thousands of warnings, one for each entry > in the database: > > [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a > corrupted dn (syntax value): zzz0107A (id 63863) > [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a > corrupted dn (syntax value): zzz MS E (id 63864) > [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a > corrupted dn (syntax value): zzz0111A (id 63865) > [28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a > corrupted dn (syntax value): zzz DR I (id 63866) > > At the end up the upgrade process, the database is completely empty, all data > has been destroyed. It should have been saved in the database backup directory - usually /var/lib/dirsrv/slapd-INSTANCE/bak > > The message "skipping an entry with a corrupted dn (syntax value)" is too vague > to be useful - it doesn't say what DN, it doesn't say what syntax value, so I'm > in the dark as what action to take. Once you restore your db, you can use dbscan -K idnumber -f /path/to/id2entry.db4 e.g. dbscan -K 63866 -f /var/lib/dirsrv/slapd-INSTANCE/db/userRoot/id2entry.db4
Upstream ticket: https://fedorahosted.org/389/ticket/5
marking as screened because it has been cloned upstream