gitea: ORM engine initialization Error: migrate: Row size too large

Or you could have just used gitea convert

https://docs.gitea.io/en-us/command-line/#convert

I’m running: mariadb Ver 15.1 Distrib 10.4.12-MariaDB, for Linux (x86_64) using readline 5.1

Nice! 😄. The original poster had one, but I didn’t know what you had.

So, you need to stop Gitea (make sure no gitea processes keep running, even if it seems to have stopped), and export/transform/re-import the database (assuming your database name is gitea):

mysqldump -u root -p gitea > original.sql
sed 's:ROW_FORMAT=COMPACT:ROW_FORMAT=DYNAMIC:g' original.sql > modified.sql
mysql -u root -p gitea < modified.sql

You will be prompted for the root user’s password two times. The original.sql script remains as a normal backup in case of trouble. Save a copy of original.sql for safekeeping purposes.

@zeripath

% mariadb --version
mariadb  Ver 15.1 Distrib 10.4.11-MariaDB, for Linux (x86_64) using readline 5.1

gitea database collation: utf8mb4_unicode_ci some tables are utf8mb4_unicode_ci, most are: utf8_general_ci

I remember there being a similar issue in Nextcloud before, requiring changing the table row format to DYNAMIC.

edit: This worked for me. Manually changing the row format and character set of each table:

# take a backup of the database

MariaDB> USE INFORMATION_SCHEMA;

# change row format
# this creates a list of SQL commands, run each manually
MariaDB> SELECT CONCAT("ALTER TABLE `", TABLE_SCHEMA,"`.`", TABLE_NAME, "` ROW_FORMAT=DYNAMIC;") AS MySQLCMD FROM TABLES WHERE TABLE_SCHEMA = "gitea";

# change collation, character set
# this creates a list of SQL commands, run each manually
MariaDB> SELECT CONCAT("ALTER TABLE `", TABLE_SCHEMA,"`.`", TABLE_NAME, "` CONVERT TO CHARACTER SET utf8mb4;") AS MySQLCMD FROM TABLES WHERE TABLE_SCHEMA = "gitea";

Adapted from: https://docs.nextcloud.com/server/11/admin_manual/maintenance/mysql_4byte_support.html#mariadb-support

It’s not a fault with MySQL, it works as intended. It’s a fault of how Gitea is using MySQL and a missing migration. If you need ROW_FORMAT=DYNAMIC specify it explicitly during table creation or at least please mention it in the documentation that dynamic is the expected row format. @zeripath @lunny

This should be added to the docs and maybe the check could be in doctor command first and if stable move to the web startup process.

So we can finally close this issue - which is a fault with MySQL not Gitea - I guess we should put this little script in the FAQ.

That did the trick, thank you @guillep2k !!

@leetNightshade I’m sorry you didn’t find that link useful. Unfortunately that’s a limitation of MySQL/MariaDB. AFAICT the problem you are facing is very common for databases created with old versions of those products. “Modern” versions of MySQL/MariaDB don’t have this problem. What you need to do is to upgrade your engine and look for a way of converting your tables to a newer format.

I’d suggest you perform a backup and upgrade to the latest database engine version possible (e.g. MariaDB 10.4.12). You can then export your database with mysqldump, modify the backup as instructed here, and import it back (you’ll need to update the script and change DB="" for DB="gitea" or whatever is the name of your database).

We could also add a function (step independent) to the migration function that attempts to create row with a deliberately big length, then delete it. If that fails, we could abort the process, warn the user and point them to the docs.