Differences

This shows you the differences between two versions of the page.

--- server:gitea [2017/11/17 18:26] – GITEA_CUSTOM Verwendung hinzugefügt sascha
+++ server:gitea [2018/08/21 15:40] (current) – Update-Problem auf Gitea 1.5 erklärt sascha
@@ Line 174: / Line 174: @@
 FIXME
+===== Update-Probleme =====
+==== Update auf Gitea 1.5 unter Arch Linux ====
+Arch Linux verwendet noch den alten 10.1 Versionszweig von MariaDB, da die [[https://lists.archlinux.org/pipermail/arch-general/2017-September/044255.html|neue Version 10.2 aufgrund von größeren Änderungen an Bibliotheksnamen und Strukturänderungen von Datentypen zu weitreichenden Problemen mit anderen Programmen führt]]. Das Problem beim Update auf Gitea 1.5 ist, dass MariaDB in der alten Version andere kleinere Datentypen verwendet, weswegen die Datenbankmigrationen im Zuge des Updates vermeintlich zu viel Platz beanspruchen. Dies macht sich in den Log-Dateien von Gitea unter ''/var/log/gitea/gitea.log'' bemerkbar:
+> 2018/08/21 13:37:00 [I] Migration: Reformat and remove incorrect topics
+> 2018/08/21 13:37:00 [I] This migration could take up to minutes, please be patient.
+> 2018/08/21 13:37:00 [...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
+Das Problem lässt sich recht einfach lösen, indem man die Option ''[[https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_large_prefix|innodb_large_prefix]]'' aktiviert, welche die Beschränkung auf 767 Bytes, die in der Fehlermeldung auftaucht, aufhebt. Um dies zu aktivieren, muss eine MySQL Shell gestartet werden und die Option aktiviert werden:
+  $ mysql -u root -p
+  > set global innodb_large_prefix = `ON`;
+  > exit;
+Wird nun Gitea mittels ''sudo systemctl restart gitea.service'' neugestartet, schlägt die Migration nicht mehr fehl und der Service kann wieder verwendet werden.