Gitea: Updated to latest version: Failed to initialize ORM engine

[Perflyst]

• Gitea version (or commit ref): 1.5.0-linux-amd64
• Git version: 2.11.0
• Operating system: Debian 4.9.88-1+deb9u1 (2018-05-07)
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [x] MySQL (Ver 15.1 Distrib 10.1.26-MariaDB, using readline 5.2)
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist:
  [...itea/routers/init.go:60 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: Sync2: Error 1709: Index column size too large. The maximum column size is 767 bytes

Description

Updated binary from v1.4.3 to v1.5.0
sha256sum is correct.

Unable to start, no more output. Above log gist is from logfile.

$ ./gitea-1.5.0-linux-amd64 
2018/08/10 20:41:02 [T] AppPath: /home/gitea/gitea-1.5.0-linux-amd64
2018/08/10 20:41:02 [T] AppWorkPath: /home/gitea
2018/08/10 20:41:02 [T] Custom path: /home/gitea/custom
2018/08/10 20:41:02 [T] Log path: /home/gitea/log

[Zeuh]

This is probably caused by table charset set to utf8mb4 or when default charset table is utf8mb4.

By default, there is some restrictions on index size in InnoDB :

• https://dev.mysql.com/doc/refman/5.5/en/innodb-restrictions.html

[Pofilo]

Same problem on same OS with MySQL too.

[tobidope]

Have the same problem on Centos. Do you plan to,fix this or document that utf8mb4 is not usable with your setup?

[tscs37]

Seems this is happening on Migration v68 on the Topic table:

[I] [SQL] CREATE UNIQUE INDEX `UQE_topic_name` ON `topic` (`name`)
[...itea/routers/init.go:60 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: Sync2: Error 1071: Specified key was too long; max key length is 767 bytes

A temporary workaround is to convert the topic table to utf8 (only this table);

alter table topic convert to character set utf8 collate utf8_unicode_ci;

[akuzia]

Had same behavior. Restored my db to 1.4.3 and then update binary. Worked, but with some data corruption on repository.description. Perhaps bad encoding. Example:

Скрипты бекапов => Скрипты бекапов

But I cant detect what coding it is.

And a bad migration on one instance:

2018/08/11 21:54:41 [...itea/routers/init.go:60 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: Insert team units: Error 1062: Duplicate entry '1-1' for key 'UQE_team_unit_s'

Then the same ORM fail message.

[lafriks]

Seems to be duplicate of #2979

[tobidope]

Setting the row_format to dynamic solved my issue with the topic table.

[lunny]

@trahibidadido just clear table team_unit and restart the gitea should resolve your issue. Your issue is different from others.

[schrodinger72]

Hi guys, I have a similar issue regarding team_unit migration:

2018/08/13 12:10:03 [I] Migration: move team units to team_unit table
2018/08/13 12:10:03 [...itea/routers/init.go:60 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: Insert team units: UNIQUE constraint failed: team_unit.team_id, team_unit.type

It seems that such unique contraint already exists:

sqlite> .schema team_unit
CREATE TABLE `team_unit` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `org_id` INTEGER NULL, `team_id` INTEGER NULL, `type` INTEGER NULL);
CREATE UNIQUE INDEX `UQE_team_unit_s` ON `team_unit` (`team_id`,`type`);
CREATE INDEX `IDX_team_unit_org_id` ON `team_unit` (`org_id`);
sqlite> select * from team_unit;
1|4|1|1
2|4|1|2
3|4|1|3
4|4|1|4
5|4|1|5
6|4|1|6
7|4|1|7
8|17|4|1
9|17|4|2
10|17|4|3
11|17|4|4
12|17|4|5
13|17|4|6
14|17|4|7
15|36|6|1
16|36|6|2
17|36|6|3
18|36|6|4
19|36|6|5
20|36|6|6
21|36|6|7

[lafriks]

just delete records from team_unit and try again

[schrodinger72]

Worked perfectly. Thanks @lafriks

[moelski]

Hi !
Just have the same issue ...
[...itea/routers/init.go:60 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: Sync2: Error 1071: Specified key was too long; max key length is 767 bytes

But I have no table which is called team_unit:
| star |
| stopwatch |
| team |
| team_repo |
| team_user |
| topic |
| tracked_time |

What can I do now? Also using MariaDB 10.

regards Dominik

[tobidope]

Set the row_format to dynamic for each table having the problem.

[moelski]

Ok but
1) how can I determine the tables
2) how can I update the row_format
?

[msphn]

@moelski aside from the Gitea.log files, you'll find a file called xorm.log, there it should show all recent sql statements. The last one is the failing one.

[msphn]

@moelski btw. the workaround from tscs37 worked for me.

[markhorrocks]

I have the same issue using AWS RDS. The link above won't solve my problem I believe.

The database settings are invalid: Error 1071: Specified key was too long; max key length is 767 bytes