Created attachment 128380 [details]
output from user

My test result is actually worse... :)
I installed 7.2 and upgraded it to 7.2 (identical), then "ds_create -r -f
<inffile>" crashed because in the upgrade case, the section for [slapd] in the
inffile is just 2 lines w/o any useful info for the DS instance:
  [slapd]
  Components=   slapd,slapd-client

Ds_create expects to go through the slapd instances, which are not available due
to the above reason.
#0  0x0804d72f in sanity_check (cf=0xbfecd1f0, param_name=0xbfeccd90 "")
    at create_instance.c:456
456         for(x=0; cf->servid[x]; x++)  {
(gdb) bt
#0  0x0804d72f in sanity_check (cf=0xbfecd1f0, param_name=0xbfeccd90 "")
    at create_instance.c:456
#1  0x0804e946 in update_server (cf=0xbfecd1f0) at create_instance.c:1404
#2  0x0804c9ff in main (argc=4, argv=0xbfecd344) at instindex.cpp:142
Current language:  auto; currently c
(gdb) p cf->servid
$1 = 0x0

I know this problem was introduced with the fix for [185364].
To fix this crash problem, we somehow need to gather slapd info either from the
user input or dse.ldif.  The problem for the latter would be the Directory
Manager password, which cannot be retrieved from dse.ldif.

It's ugly, but could it be acceptable to add some code in the script ns-update
when it's running as upgrade mode to ask for the Directory Manager password,
then add the necessary info to the inf file?  Also, when multiple DS instances
need to be upgraded, it's not supported for now (see [185364]).  It'd be nice
that ns-update handles the case, too.

I added complete info to the <inffile>, then ran ds_create -r with the file. 
Then, ds_create itself was successfully finished. 
  $ ./ds_create -r -f  /tmp/upgrade.inf
  Start Slapd Starting Slapd server reconfiguration.
  Info Slapd No old nsperl references found

The last message "No old nsperl references found" makes me puzzled, though. 
There should be some nsperl ghost hiding...

What information does ds_create need?  We ask the user for the admin
user/password during upgrade - could we use that instead of the dirmgr password?

We should get rid of that nsperl stuff . . .

I guess we need both passwords: admin user and dirmgr.
If there are multiple DS instances, we need the dirmgr password for each...

I'm going to investigate who is still referring nsperl. :)