+++ This bug was initially created as a clone of Bug #729369 +++

Description of problem:
upgrade DB to upgrade from entrydn to entryrdn format is not working.

I have shared all the details on IRC/mail.
Please let me know in case more details needed.

Server is not getting started after upgrade from 8.2 to 9.0.

--- Additional comment from rmeggins on 2011-08-09 17:17:25 EDT ---

will have to change the docs

the problem is that the procedure on the target machine is this:

tar xf ....
setup-ds.pl -u General.UpdateMode=offline
service dirsrv start
setup-ds-admin.pl -u

That is, you have to first run setup-ds.pl -u General.UpdateMode=offline with
the servers shutdown before you can start them successfully.

--- Additional comment from amsharma on 2011-08-10 03:25:34 EDT ---

On Target
==============

1. cd /
2. tar xfjp /home/myfile.tar.bz2

3. Note: I did not do "remove /etc/dirsrv/slapd-dhcp201-140/schema/05rfc2247.ldif and 28pilot.ldif"
 And executed - setup-ds.pl -u General.UpdateMode=offline
=======================================================================
Which update mode do you want to use? [quit]: Offline
[10/Aug/2011:12:31:50 +051800] - check_and_set_import_cache: pagesize: 4096, pages: 125898, procpages: 47616
[10/Aug/2011:12:31:50 +051800] - WARNING: After allocating import cache 201436KB, the available memory is 302156KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import.
[10/Aug/2011:12:31:50 +051800] - Import allocates 201436KB import cache.
[10/Aug/2011:12:31:50 +051800] Upgrade DN Format - userRoot: Start upgrade dn format.
[10/Aug/2011:12:31:50 +051800] Upgrade DN Format - Instance userRoot in /var/lib/dirsrv/slapd-dhcp201-140/db/userRoot is up-to-date
Finished successful update of directory server.
Please restart your directory servers.
Exiting . . .
Log file is '/tmp/setuplQE7am.log'
==========================================================================
4. service dirsrv start
But I am not able to start the dirsrv, Getting errors:
====================================================================
[root@dhcp201-140 /]# service dirsrv start
Starting dirsrv: 
    dhcp201-140...                                         [FAILED]
  *** Warning: 1 instance(s) failed to start
===================================================================
5. [root@dhcp201-140 /]# tail -f /var/log/dirsrv/slapd-dhcp201-140/errors
[10/Aug/2011:12:32:36 +051800] - Error: preoperation plugin ACL preoperation is not started
[10/Aug/2011:12:32:36 +051800] - Error: object plugin Class of Service is not started
[10/Aug/2011:12:32:36 +051800] - Error: preoperation plugin deref is not started
[10/Aug/2011:12:32:36 +051800] - Error: preoperation plugin HTTP Client is not started
[10/Aug/2011:12:32:36 +051800] - Error: database plugin ldbm database is not started
[10/Aug/2011:12:32:36 +051800] - Error: object plugin Legacy Replication Plugin is not started
[10/Aug/2011:12:32:36 +051800] - Error: preoperation plugin Linked Attributes is not started
[10/Aug/2011:12:32:36 +051800] - Error: object plugin Multimaster Replication Plugin is not started
[10/Aug/2011:12:32:36 +051800] - Error: object plugin Roles Plugin is not started
[10/Aug/2011:12:32:36 +051800] - Error: object plugin Views is not started

6. Then, I carefully read the error logs : there was - 
[10/Aug/2011:12:32:35 +051800] - nsslapd-subtree-rename-switch is on, while the instance userRoot is in the DN format. Please run dn2rdn to convert the database format.
[10/Aug/2011:12:32:35 +051800] - start: Failed to start databases, err=-1 Unknown error: -1
[10/Aug/2011:12:32:35 +051800] - Failed to start database plugin ldbm database

7. I modified the dse.ldif - nsslapd-subtree-rename-switch: off (It was on initailly)
(I checked this was not in the source macine).

8. After this, dirsrv instance got started.
[root@dhcp201-140 /]# service dirsrv start
Starting dirsrv: 
    dhcp201-140...                                         [  OK  ]

9. Also, the upgrade was a success, I mean I am able to see all the data with ldapsearch.

But I did not get the logic behind this initial error and also what I did, how it resolved the issue?
Also, Is this the right way to do it?

--- Additional comment from rmeggins on 2011-08-10 15:21:01 EDT ---

Created attachment 517678 [details]
0001-Bug-729369-upgrade-DB-to-upgrade-from-entrydn-to-ent.patch

--- Additional comment from nhosoi on 2011-08-10 16:12:59 EDT ---

Comment on attachment 517678 [details]
0001-Bug-729369-upgrade-DB-to-upgrade-from-entrydn-to-ent.patch

You are right.  Now, I'm confused how the upgrade from 389 1.2.5 to the newer version worked...  ( or it was not working at all??? ):

--- Additional comment from rmeggins on 2011-08-10 16:26:45 EDT ---

(In reply to comment #4)
> Comment on attachment 517678 [details]
> 0001-Bug-729369-upgrade-DB-to-upgrade-from-entrydn-to-ent.patch
> 
> You are right.  Now, I'm confused how the upgrade from 389 1.2.5 to the newer
> version worked...  ( or it was not working at all??? ):

I don't know.  We're going to need a lot of testing from community members to upgrade to 1.2.9.6 from 1.2.9.5 and earlier . . .

--- Additional comment from rmeggins on 2011-08-10 16:39:08 EDT ---

To ssh://git.fedorahosted.org/git/389/ds.git
   de75e6d..062c4d9  master -> master
commit 062c4d9df34998ac15817406e73a6b0fe6928120
Author: Rich Megginson <rmeggins>
Date:   Wed Aug 10 13:17:47 2011 -0600
    Reviewed by: nhosoi (Thanks!)
    Branch: master
    Fix Description: Looks like the test to see if upgrade should proceed is
    only looking at the old IDL to new IDL case, not the upgrade from earlier
    versions of bdb, nor the upgrade DN to RDN case.
    Also, there was no way to pass the -f (force) flag to dn2rdn to force
    the conversion.
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no