Upgrade from 20.07 to 20.09 failed

ℹ️ Support
1
Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 20.07
Operating system and version (eg, Ubuntu 20.04): Solaris 11.4
Apache or nginx version (eg, Apache 2.4.25): 2.4.46
PHP version (eg, 7.4): 7.3.23

The issue you are facing:
Fails to upgrade to 20.09
Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Start upgrade via the BUI

The output of your Nextcloud log in Admin > Logging:

Checked for update of app "workflowengine" in appstore

Repair step: Repair MySQL collation

Repair info: Change row format for oc_activity ...

Repair info: Change collation for oc_activity ...

Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'ALTER TABLE `oc_activity` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;': SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'passwordsalt' => '',
  'secret' => '',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => '192.168.0.66',
    2 => '192.168.0.66:643',
    3 => 'ytc-cloud:643',
    4 => 'ytc1-cloud.dyndns.org:643',
    5 => 'ytc1.dyndns.org:643',
    6 => 'ytc-cloud:80',
  ),
  'datadirectory' => '/nextcloud/server/nextcloud/data',
  'overwrite.cli.url' => 'http://localhost',
  'dbtype' => 'mysql',
  'version' => '20.0.7.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'oc_admin',
  'dbpassword' => '',
  'logtimezone' => 'UTC',
  'installed' => true,
  'instanceid' => 'oc798ms43svp',
  'loglevel' => 0,
  'mail_from_address' => '',
  'mail_smtpmode' => 'sendmail',
  'mail_domain' => ',
  'auth.bruteforce.protection.enabled' => false,
  'theme' => '',
  'mail_sendmailmode' => 'smtp',
  'maintenance' => false,
  'mysql.utf8mb4' => true,
);

The output of your Apache/nginx/system log in /var/log/____:

Sorry, I have rolled back the filesystem and therefore that log is not relevant
2

Hi !

Have you tried : sudo -u www-data php occ db:add-missing-indices and sudo -u www-data php occ db:add-missing-columns ?

3

It didn’t report any issues.

Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Done.

sudo -u webservd php occ db:add-missing-columns
Check columns of the comments table.
Done.

4

Interesting, over on github I see this.

Which suggests either setting “mysql.utf8mb4’ => false” or following Enabling MySQL 4-byte support — Nextcloud latest Administration Manual latest documentation

I ran this last year, and I can see I have
—8<
mysql> show variables like ‘innodb_file_per_table’;
±----------------------±------+
| Variable_name | Value |
±----------------------±------+
| innodb_file_per_table | ON |
±----------------------±------+

show variables like ‘innodb_file_format’;
±-------------------±----------+
| Variable_name | Value |
±-------------------±----------+
| innodb_file_format | Barracuda |
±-------------------±----------+
1 row in set (0.00 sec)

—8<

Out of curiosity I ran the repair
—8<
sudo -u webservd php occ maintenance:repair

  • Repair MySQL collation
    • Change row format for oc_activity …
    • Change collation for oc_activity …

In AbstractMySQLDriver.php line 106:

An exception occurred while executing ‘ALTER TABLE oc_activity CONVERT TO
CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;’:

SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large.
The maximum row size for the used table type, not counting BLOBs, is 65535
. This includes storage overhead, check the manual. You have to change some
columns to TEXT or BLOBs

In PDOStatement.php line 129:

SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large.
The maximum row size for the used table type, not counting BLOBs, is 65535
. This includes storage overhead, check the manual. You have to change some
columns to TEXT or BLOBs

In PDOStatement.php line 127:

SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large.
The maximum row size for the used table type, not counting BLOBs, is 65535
. This includes storage overhead, check the manual. You have to change some
columns to TEXT or BLOBs

maintenance:repair [–include-expensive]
—8<

I suppose I could just disable the mysql.utf8mb4 and see if the upgrade goes through, and then come back looking how to fix the utf8mb4 issue?

5

To answer my own question, yes, by changing the mysql.utf8mb4 to false enables a succesful upgrade.
This leaves with trying to work out how to fix the resulting in the “Overview” pane.