I hope that ekacnet (our upgradeprovision specialist) will handle this.

Paul 
I must confess that I never tried it against a openldap backend.

From the error message it's a very early failure that you face which probably mean that we will have tons of others ...

Can you give me the output of:
mat@ares:~/workspace/samba/testprov/private$ /usr/local/src/samba4/source4/bin/ldbsearch -H sam.ldb -b "CN=Configuration,DC=test,DC=local" cn=Sites

Hi Matthieu,
the output of the command you requested is as follows:
# returned 0 records
# 0 entries
# 0 referrals

(which matches the error in the upgrade, I guess)

Not quite sure but as I am using OpenLdap backend, shouldn't the call be instead:
ldbsearch -H ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi -b "CN=Configuration,DC=test,DC=local" cn=Sites

which in return will present
search error - LDAP error 32 LDAP_NO_SUCH_OBJECT -  <> <>

Let me know whether I should run any other tests for you.

Regards,
  Dirk

Hi Matthieu,
just saw that for my 1st answer, I was not at the correct folder:

so, from /usr/local/samba/private
the command 
ldbsearch -H sam.ldb -b "CN=Configuration,DC=test,DC=local" cn=Sites
returns:
schema_fsmo_init: no schema head present: (skip schema loading)
naming_fsmo_init: no partitions dn present: (skip loading of naming contexts details)
pdc_fsmo_init: no domain object present: (skip loading of domain details)
search error - LDAP error 32 LDAP_NO_SUCH_OBJECT -  <> <>

Regards,
  Dirk

At the moment we are fixing some problems regarding the directory backends in s4 - maybe afterwards also this will be okay again.

Well, the directory backends should have been fixed again by some patches of our backends specialist Endi. Dirk, please check out a new release from our GIT repo and retry!

sorry, still fails with recompiled master (release-4-0-0alpha11-66-g204e4b2) from git:

sudo ./scripting/bin/upgradeprovision -s /usr/local/samba/etc/smb.conf
schema_load_init: no schema head present: (skip schema loading)

Traceback (most recent call last):
  File "./scripting/bin/upgradeprovision", line 822, in <module>
    names = guess_names_from_current_provision(creds,session,paths)
  File "./scripting/bin/upgradeprovision", line 219, in guess_names_from_current
_provision
    res3= samdb.search(expression="(objectClass=*)",base="CN=Sites,"+configdn, s
cope=SCOPE_ONELEVEL, attrs=attrs3)
_ldb.LdbError: (32, 'No such Base DN: CN=Sites,CN=Configuration,DC=test,D
C=local')

but be aware that I also reopened BUG 7040

Endi, are you able to help here?

just be aware that currently also provioning of a new domain fails again: Bug 7304

Dirk, please retry this to see if it works again.

used latest git commit (5beaef7cde3c311e4543abf71e5fe9794d62cc6e)
cannot test: compilation runs into a fatal error:
Compiling libnet/libnet_time.c
libnet/libnet_time.c: In function ‘libnet_RemoteTOD_srvsvc’:
libnet/libnet_time.c:57: error: incompatible types when assigning to type ‘NTSTA
TUS’ from type ‘int’
The following command failed:
gcc -Iheimdal/kdc -Iheimdal/lib/hdb -Iheimdal/../heimdal_build -Iheimdal/lib/hdb
    -I/usr/include/python2.6 -I/usr/include/python2.6   -Ilib/ldb/include -Ilib/
ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/incl
ude -Iheimdal/../heimdal_build -Iheimdal/lib/gssapi -Iheimdal/lib/gssapi/gssapi 
-Iheimdal/lib/gssapi/spnego -Iheimdal/lib/gssapi/krb5 -Iheimdal/lib/gssapi/mech 
-Iheimdal_build -Iheimdal/lib/roken -Iheimdal/lib/gssapi -Iheimdal/lib/gssapi   
  -Iheimdal/../heimdal_build -Iheimdal/lib/hdb -Iheimdal/lib/hdb     -Ilib/ldb/i
nclude -Ilib/ldb/include -Ilib/ldb/ldb_tdb -Ilib/ldb/include -Ilib/ldb/include -
Ilib/ldb/include -I../lib/tdb/include      -I./../lib/talloc   -Iheimdal/../heim
dal_build -Iheimdal/lib/krb5 -Iheimdal/lib/asn1 -Iheimdal/lib/com_err   -Iheimda
l/../heimdal_build -Iheimdal/lib/hx509 -Iheimdal/lib/hx509 -Iheimdal/lib/asn1 -I
heimdal/lib/asn1 -Iheimdal/lib/asn1 -Iheimdal/lib/hx509 -Iheimdal/../heimdal_bui
ld -Iheimdal/lib/hcrypto -Iheimdal/lib -Iheimdal/../heimdal_build -Iheimdal/lib/
hcrypto/imath -Iheimdal/../heimdal_build -Iheimdal/lib/wind -Iheimdal/lib/asn1 -
Iheimdal/lib/asn1 -Iheimdal/lib/asn1 -Iheimdal/lib/asn1 -Iheimdal/../heimdal_bui
ld -Iheimdal/lib/asn1 -Iheimdal/../heimdal_build -Iheimdal/lib/com_err -Iheimdal
/../heimdal_build -Iheimdal/lib/roken -Iheimdal/include -I../lib/socket_wrapper 
  -Ilib/events -I../lib/tevent       -I../lib/talloc -Ilib/replace     -fPIC -I.
/include -I. -I./lib -I./../lib/replace -I./../lib/talloc -I./.. -D_SAMBA_BUILD_
=4 -DHAVE_CONFIG_H  -c libnet/libnet_time.c -o libnet/libnet_time.o
make: *** [libnet/libnet_time.o] Fehler 1

Can you please stop spamming this bug report with unrelated problems?

Yes, a particular snapshot may from time to time fail to compile.  Just try again a bit later, after checking it still fails with a clean checkout.

Then, if you must, file a new bug (we notice broken builds pretty quickly however). 

Thanks,

addad bug 7344 on the compilation error, which prevents further testing here.

@Andrew: BTW, before telling me a "spammer" next time, you should ask yourself whether you want people spending their time in retests and reporting the outcome or not! In this special case, I do not feel that my post was unreleated, though

rechecked with a compilation from commit 1a2734336655a8d4256c8cce039ada66650b70a9:
- autoconfig / configure / make ok
- sudo service samba stop
(service openldap still is running)
- sudo ./scripting/bin/upgradeprovision -s /usr/local/samba/etc/smb.conf
still fails:

schema_load_init: no schema head present: (skip schema loading)

module schema_load initialization failed
module kludge_acl initialization failed
module operational initialization failed
module acl initialization failed
module descriptor initialization failed
module objectclass initialization failed
module asq initialization failed
module server_sort initialization failed
module paged_results initialization failed
module lazy_commit initialization failed
module rootdse initialization failed
module samba_dsdb initialization failed
Unable to load modules for /usr/local/samba/private/sam.ldb: (null)
Traceback (most recent call last):
  File "./scripting/bin/upgradeprovision", line 925, in <module>
    names = find_provision_key_parameters(param, creds, session, paths, smbconf)
  File "bin/python/samba/upgradehelpers.py", line 96, in find_provision_key_para
meters
    credentials=credentials, lp=lp, options=["modules:samba_dsdb"])
  File "bin/python/samba/__init__.py", line 111, in __init__
    self.connect(url, flags, options)
_ldb.LdbError: (80, None)


Am I understanding the upgrade-provision.txt not correct?

The problem is that upgradeprovision was never written with the LDAP backends in mind.

We will keep this bug open, and work to address whatever issues we can as a feature request, frankly this isn't expected to work. 

(Part of the issue is that LDAP backends do not have transactions, and do not allow us to do other 'illegal' things we can do with direct LDB).

Dirk, has the situation in the meantime improved a bit?

I do not use OpenLDap as backend; I set up a new installation w/o OpenLDap, so I cannot answer this question

We have decided to no longer support the OpenLDAP backend, partly because of issues such as this (it is just not possible to do this safely). 

I realise this leaves you in a difficult position, but we would rather say this now than have you expect this to be supported into the future.