Failed to upgrade to OC 10.0.1

Steps to reproduce

  1. sudo -u www php occ upgrade
    2.
    3.

Expected behaviour

Upgrading from 10.0.0 to 10.0.1

Actual behaviour

MySql triggers the following exception:

Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'CREATE TABLE oc_account_terms (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, account_id BIGINT UNSIGNED NOT NULL, term VARCHAR(256) NOT NULL, INDEX account_id_index (account_id), INDEX term_index (term), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = InnoDB':

SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes
Update failed

Server configuration

Operating system: FreeBSD 10.0.3

Web server:
Nginx

Database:
mysql Ver 14.14 Distrib 5.6.36, for FreeBSD10.3 (amd64) using EditLine wrapper

PHP version:
PHP 5.6.30 (cli) (built: Mar 26 2017 07:21:27)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

ownCloud version: (see ownCloud admin page)

10.0.0

Updated from an older ownCloud or fresh install:

Where did you install ownCloud from:

Freebsd 's ports tree

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

timeout

The content of config/config.php:

No access

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Enabled:
- activity: 2.3.4
- calendar: 1.4.2
- comments: 0.3.0
- configreport: 0.1.1
- contacts: 1.5.2
- dav: 0.2.8
- federatedfilesharing: 0.3.0
- federation: 0.1.0
- files: 1.5.1
- files_external: 0.7.0
- files_pdfviewer: 0.8.2
- files_sharing: 0.10.0
- files_texteditor: 2.2
- files_trashbin: 0.9.0
- files_versions: 1.3.0
- files_videoplayer: 0.9.8
- firstrunwizard: 1.1
- market: 0.1.0
- notifications: 0.3.0
- provisioning_api: 0.5.0
- systemtags: 0.3.0
- templateeditor: 0.1
- updatenotification: 0.2.1
Disabled:
- encryption
- external
- files_Enabled:
- activity: 2.3.4
- calendar: 1.4.2
- comments: 0.3.0
- configreport: 0.1.1
- contacts: 1.5.2
- dav: 0.2.8
- federatedfilesharing: 0.3.0
- federation: 0.1.0
- files: 1.5.1
- files_external: 0.7.0
- files_pdfviewer: 0.8.2
- files_sharing: 0.10.0
- files_texteditor: 2.2
- files_trashbin: 0.9.0
- files_versions: 1.3.0
- files_videoplayer: 0.9.8
- firstrunwizard: 1.1
- market: 0.1.0
- notifications: 0.3.0
- provisioning_api: 0.5.0
- systemtags: 0.3.0
- templateeditor: 0.1
- updatenotification: 0.2.1
Disabled:
- encryption
- external
- files_antivirus
- theme-example
- user_external
antivirus
- theme-example
- user_external

Are you using external storage, if yes which one: local/smb/sftp/...

No

Are you using encryption: yes/no

No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

No

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder

not defined

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

I also tried to create a table named 'oc_account_term' into the database 'owncloud', with the same entries by myself, using the mysql command line. Same error occured, with or without the innodb engine clause.

I'm not good enough with Mysql/InnoDB internals, but using VARCHAR(255) instead of VARCHAR(256) is somehow accepted on the command line …
So, do I only need to setup Mysql in a suitable way to make it granted VARCHAR(256) ?

As this is a FreeBSD port, you should probably raise it with the package maintainers first.

I did post a request on the freebsd ports mailing list at first place.
But, by the fact, the issue may regard to a table definition for the database engine. If true, the issue might be related to a mysql installation and/or configutation, not only to a FreeBSD usecase.
So, I wonder if there is not some clauses that are missing to be fully granted by Mysql in any way.

OK, they are working on a fix.