Problem after upgrading to 9.1.3 - please help

Today I upgraded my 8.2.9 to 9.1.3 but I received an error during the installation.. would you please help me to solve it ?

Thank you very much.

Preparing update
Set log level to debug
Turned on maintenance mode
Checking whether the database schema can be updated (this can take a long time depending on the database size)
[1 / 24]: Checking table oc_appconfig
[2 / 24]: Checking table oc_storages
[3 / 24]: Checking table oc_mounts
[4 / 24]: Checking table oc_mimetypes
[5 / 24]: Checking table oc_filecache
[6 / 24]: Checking table oc_group_user
[7 / 24]: Checking table oc_group_admin
[8 / 24]: Checking table oc_groups
[9 / 24]: Checking table oc_preferences
[10 / 24]: Checking table oc_properties
[11 / 24]: Checking table oc_share
[12 / 24]: Checking table oc_jobs
[13 / 24]: Checking table oc_users
[14 / 24]: Checking table oc_authtoken
[15 / 24]: Checking table oc_vcategory
[16 / 24]: Checking table oc_vcategory_to_object
[17 / 24]: Checking table oc_systemtag
[18 / 24]: Checking table oc_systemtag_object_mapping
[19 / 24]: Checking table oc_systemtag_group
[20 / 24]: Checking table oc_privatedata
[21 / 24]: Checking table oc_file_locks
[22 / 24]: Checking table oc_comments
[23 / 24]: Checking table oc_comments_read_markers
[24 / 24]: Checking table oc_credentials
Checked database schema update
Checking updates of apps
Checking whether the database schema for activity can be updated (this can take a long time depending on the database size)
[1 / 2]: Checking table oc_activity
[2 / 2]: Checking table oc_activity_mq
Checking whether the database schema for federatedfilesharing can be updated (this can take a long time depending on the database size)
[1 / 1]: Checking table oc_federated_reshares
Checking whether the database schema for federation can be updated (this can take a long time depending on the database size)
[1 / 1]: Checking table oc_trusted_servers
Checking whether the database schema for files_antivirus can be updated (this can take a long time depending on the database size)
[1 / 2]: Checking table oc_files_antivirus
[2 / 2]: Checking table oc_files_avir_status
Checking whether the database schema for files_external can be updated (this can take a long time depending on the database size)
[1 / 4]: Checking table oc_external_mounts
[2 / 4]: Checking table oc_external_applicable
[3 / 4]: Checking table oc_external_config
[4 / 4]: Checking table oc_external_options
Checking whether the database schema for files_sharing can be updated (this can take a long time depending on the database size)
[1 / 1]: Checking table oc_share_external
Checking whether the database schema for files_trashbin can be updated (this can take a long time depending on the database size)
[1 / 1]: Checking table oc_files_trash
Checking whether the database schema for notifications can be updated (this can take a long time depending on the database size)
[1 / 1]: Checking table oc_notifications
Checked database schema update for apps
Updating database schema
Updated database
Updated "federatedfilesharing" to 0.3.0
Updated "gallery" to 15.0.0
Updated "provisioning_api" to 0.5.0
Updated "updatenotification" to 0.2.1
Updated "federation" to 0.1.0
Updated "files" to 1.5.1
Updated "activity" to 2.3.2
Updated "files_antivirus" to 0.9.0.0
Updated "files_external" to 0.6.0
Updated "files_sharing" to 0.10.0
Updated "files_trashbin" to 0.9.0
Updated "files_versions" to 1.3.0
Updated "comments" to 0.3.0
Updated "notifications" to 0.3.0
Updated "systemtags" to 0.3.0
dav: An exception occurred while executing 'CREATE TABLE `oc_addressbooks` (`id` BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, `principaluri` VARCHAR(255) DEFAULT NULL, `displayname` VARCHAR(255) DEFAULT NULL, `uri` VARCHAR(255) DEFAULT NULL, `description` VARCHAR(255) DEFAULT NULL, `synctoken` INT UNSIGNED DEFAULT 1 NOT NULL, UNIQUE INDEX addressbook_index (`principaluri`, `uri`), PRIMARY KEY(`id`)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = InnoDB': SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'oc_addressbooks' already exists

It's not recommend to skip major versions during upgrade. If you have a back-up, revert to 8.2.9, then upgrade to 9.0.7, and then to 9.1.3.

Thank you for your reply

I have not skipped.. first I upgraded to 9.0.7 !!

So you actually saw this error upgrading from 9.0.7 to 9.1.3. Okay. What database type are you running?

There already are several issues filed in GitHub describing this error. I suggest you read through some of those for clues.

Thank you for your reply,

This is what actually happened :

I read the documentation so I noticed that I have to migrate to OC 9.0.x first, so I downloaded the latest 9.0.7 version , removed all of my previous data except config and data directories and then uploaded OC files in my host.
Then I visited my URL where 8.2.9 was previously installed and clicked on update .. everything went well till it got to the posit where it says : "Updated "provisioning_api" to 0.4.1"

Then it stuck and after a while it returned with "An error occurred."

And then tried to update to 9.1 -or- re-update to 9.0.7 and this error happened.

Really appreciate your help.

In your description, you didn't mention whether or not you moved your old config.php into the new 9.0.7 config folder. I presume you did, but you really should clarify these things.

Was any more detailed message written into the logs?

Are you upgrading via web interface or command line? If the former, can you try the latter instead?

Otherwise, you should go through the process of filing an issue in GitHub with all the details required there.

I really appreciate your help ... Thank you

And Update :

I also asked my server admin to update using SSH and the same issue happened !!! and even they mentioned that I should ask for help here :frowning:

Regarding your question :

Well, I did no t remove the old /config directory in the first place.

  • I tested both methods .. both stuck in "Updated "provisioning_api" to 0.4.1" ... (my server admin tested the command line)

  • Would you please tell me what is the latter ?

  • Additional details about my server:

  • OS : CloudLinux
  • DB : MariaDB (I think they also tried directives regarding MariaDB Upgrad)
  • WebServer : LiteSpeed

The admin guy also mentioned this:

"I have found following discussion regarding to this issue in https://github.com/owncloud/core/issues/23610 . It seems that this issue is connected to the one you're experiencing so this may help you in finding source of the issue and troubleshooting upgrade process further."

Again thank you for your help.