[SOLVED] Upgrade gitea 1.6 to 1.7 problem

When upgrading from gitea 1.6.4 to any 1.7 (archlinux builds up to 1.7.2-1) a working instance starts to put errors on navigating to repo or creating a repo (template: repo/header can’t evaluate field Can Be Forked).

DB postgresql.

Downgrading back to 1.6.4-1 solves the issue, so the problem starts with 1.7.
I’m not expert in gitea, go and gitea debugging, so tell me how can I help with logs and other data.

Regards.

Do you use customized templates?

Only custom logo on header, nothing else.

Same problem here. On CentOS7

We have found out it is the db schema. If you start 1.7 with a clean DB everything is fine. With a DB coming from version 1.5 it went wrong. So what is changed?

Bump!

Problem still exist, also with newer version: 1.7.1 or 1.7.2.
We have tried to export the DB and to import it again. But still issues:

systemctl status gitea

● gitea.service - Gitea
   Loaded: loaded (/usr/lib/systemd/system/gitea.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since ma 2019-02-25 12:39:29 CET; 4s ago
  Process: 127538 ExecStart=/data/gitea/gitea web --config /data/gitea/custom/conf/app.ini (code=exited, status=2)
 Main PID: 127538 (code=exited, status=2)

feb 25 12:39:29 web-gitea-temp systemd[1]: gitea.service: main process exited, code=exited, status=2/INVALIDARGUMENT
feb 25 12:39:29 web systemd[1]: Unit gitea.service entered failed state.
feb 25 12:39:29 web systemd[1]: gitea.service failed.
feb 25 12:39:29 web systemd[1]: gitea.service holdoff time over, scheduling restart.
feb 25 12:39:29 web systemd[1]: Stopped Gitea.
feb 25 12:39:29 web systemd[1]: start request repeated too quickly for gitea.service
feb 25 12:39:29 web systemd[1]: Failed to start Gitea.
feb 25 12:39:29 web systemd[1]: Unit gitea.service entered failed state.
feb 25 12:39:29 web systemd[1]: gitea.service failed.


Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;36m[T] AppPath: /data/gitea/gitea#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;36m[T] AppWorkPath: /data/gitea#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;36m[T] Custom path: /data/gitea/custom#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;36m[T] Log path: /data/gitea/log#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] PING DATABASE sqlite3#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] Gitea v1.7.2 built with go1.11.5 : bindata, sqlite, sqlite_unlock_notify#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] Log Mode: Console(Info)#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] XORM Log Mode: Console(Info)#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] Cache Service Enabled#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] Session Service Enabled#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] Migration: add pull request rebase with merge commit#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? []interface {}{"version"}#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? and ((sql like '%`id`%') or (sql like '%[id]%')) [version]#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? and ((sql like '%`version`%') or (sql like '%[version]%')) [version]#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] [SQL] SELECT `id`, `version` FROM `version` WHERE `id`=? LIMIT 1 []interface {}{1}#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] [SQL] BEGIN TRANSACTION#033[0m
Feb 25 12:39:29 web gitea: 2019/02/25 12:39:29 #033[1;32m[I] [SQL] SELECT `id`, `repo_id`, `type`, `config`, `created_unix` FROM `repo_unit` WHERE (`type` = ?) []interface {}{3}#033[0m
Feb 25 12:39:29 web gitea: panic: interface conversion: interface {} is float64, not bool
Feb 25 12:39:29 web gitea: goroutine 1 [running]:
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/models/migrations.addPullRequestRebaseWithMerge(0xc0005f28f0, 0x0, 0x0)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/models/migrations/v76.go:44 +0x6e9
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/models/migrations.(*migration).Migrate(0xc0001ca5a0, 0xc0005f28f0, 0xc0004e7650, 0x1)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/models/migrations/migrations.go:53 +0x34
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/models/migrations.Migrate(0xc0005f28f0, 0x0, 0x0)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/models/migrations/migrations.go:247 +0x368
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/models.NewEngine(0x18040c8, 0xc, 0xc0004e7788)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/models/models.go:302 +0x70
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/routers.GlobalInit()
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/routers/init.go:60 +0x51a
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/cmd.runWeb(0xc0001f5540, 0x0, 0x0)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/cmd/web.go:121 +0xaa
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/vendor/github.com/urfave/cli.HandleAction(0x15ab180, 0x1803f88, 0xc0001f5540, 0xc000033300, 0x0)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:471 +0xad
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/vendor/github.com/urfave/cli.Command.Run(0x17860aa, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x17ae9aa, 0x16, 0x0, ...)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/command.go:191 +0x97f
Feb 25 12:39:29 web gitea: code.gitea.io/gitea/vendor/github.com/urfave/cli.(*App).Run(0xc0000b3d40, 0xc0000300c0, 0x4, 0x4, 0x0, 0x0)
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:241 +0x5a2
Feb 25 12:39:29 web gitea: main.main()
Feb 25 12:39:29 web gitea: /go/src/code.gitea.io/gitea/main.go:57 +0x43

Are you running on Docker containers, and if so have you specified your db-version with tags or are you using postgres:latest?

We ran in to issues when going from postgres:10 to postgres:11, as this could not be done automatically. If you think this could be the issue I’d be happy to describe our method for upgrading the database in case it is different from your method of exporting and importing. If you are certain the db version isn’t constant, that is.

We do not use docker, gitea + sqlite.

and since 1.7.x we see those errors:

gitea: 2019/02/26 11:54:16 #033[1;32m[I] [SQL] SELECT name FROM sqlite_master WHERE type=‘table’ and name = ? []interface {}{“version”}#033[

As I said in my original post, it’s about regular builds (archlinux repo in my case) and it starts with the upgrade from version 1.6 to 1.7. It affects upgrades, it seems it doesn’t affect fresh installs, so it’s very likely something regarding the DB scheme, probably some “migration” scripts missing. It’s not about the database used, since the problem affects both PostgreSQL and MariaDB based instances and probably SQLite too.
When I find some time, I’ll test also, if the problem persists with the gitea build based on current github code, but i suspect it does. It would be probably useful to test the 1.7 release candidate to establish, if the problem was already there, but I doubt I’ll be able to do it in the next few months since I’m quite busy in this period.

I agree, its the DB schema.

I have solved my problem by (migrate from Sqlite to MariaDB):

  • gitea dump (gitea dump) (with old gitea in my case: 1.5.0)
  • open sql file (sqlite file) and remove all CREATE ( in vim :g/CREATE/d )
  • save your app.ini file (mv app.ini app.ini.org)
  • stop gitea with systemctl
  • start gitea 1.7.2 and install with MariaDB database backend
  • import your sql file (made with gitea dump and edit with vim so only your INSERT queries) on your mairadb gitea db
  • place your app.ini.org back to app.ini
  • start gitea with systemctl
  • done, you have Gitea 1.7.2 with mariadb working + your data.

Maybe its also possible to migrate back to Sqlite but Mariadb is okey for us.

Hello,
I currently have the same problem.
Gitea inside a docker + sqlite.
I encounter the same error.
Here is the complete startup log from latest docker build (gitea/gitea:latest)

2019/03/04 14:45:37 [T] AppPath: /app/gitea/gitea,
2019/03/04 14:45:37 [T] AppWorkPath: /app/gitea,
2019/03/04 14:45:37 [T] Custom path: /data/gitea,
2019/03/04 14:45:37 [T] Log path: /data/gitea/log,
2019/03/04 14:45:37 [I] Gitea v8e202e2 built with go1.11.5 : bindata, sqlite, sqlite_unlock_notify,
2019/03/04 14:45:37 [I] Log Mode: Console(Info),
2019/03/04 14:45:37 [I] XORM Log Mode: Console(Info),
2019/03/04 14:45:37 [I] Cache Service Enabled,
2019/03/04 14:45:37 [I] Session Service Enabled,
2019/03/04 14:45:37 [I] Beginning ORM engine initialization.,
2019/03/04 14:45:37 [I] ORM engine initialization attempt #1/10...,
2019/03/04 14:45:37 [I] PING DATABASE sqlite3,
2019/03/04 14:45:37 [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? []interface {}{"version"},
2019/03/04 14:45:37 [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? and ((sql like '%`id`%') or (sql like '%[id]%')) [version],
2019/03/04 14:45:37 [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? and ((sql like '%`version`%') or (sql like '%[version]%')) [version],
2019/03/04 14:45:37 [I] [SQL] SELECT `id`, `version` FROM `version` WHERE `id`=? LIMIT 1 []interface {}{1},
2019/03/04 14:45:37 [I] [SQL] BEGIN TRANSACTION,
2019/03/04 14:45:37 [I] [SQL] SELECT `id`, `repo_id`, `type`, `config`, `created_unix` FROM `repo_unit` WHERE (`type` = ?) []interface {}{3},
2019/03/04 14:45:37 [I] Migration: add pull request rebase with merge commit,
,
panic: interface conversion: interface {} is float64, not bool,
goroutine 1 [running]:,
code.gitea.io/gitea/models/migrations.addPullRequestRebaseWithMerge(0xc00055f2b0, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/models/migrations/v76.go:44 +0x6e9,
code.gitea.io/gitea/models/migrations.(*migration).Migrate(0xc0005fa0e0, 0xc00055f2b0, 0xc0005f9588, 0x1),
	/go/src/code.gitea.io/gitea/models/migrations/migrations.go:54 +0x34,
code.gitea.io/gitea/models/migrations.Migrate(0xc00055f2b0, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/models/migrations/migrations.go:256 +0x368,
code.gitea.io/gitea/models.NewEngine(0x18c7690, 0x2b, 0xc0005f9698),
	/go/src/code.gitea.io/gitea/models/models.go:289 +0x70,
code.gitea.io/gitea/routers.initDBEngine(0x1854340, 0xc),
	/go/src/code.gitea.io/gitea/routers/init.go:52 +0x29c,
code.gitea.io/gitea/routers.GlobalInit(),
	/go/src/code.gitea.io/gitea/routers/init.go:79 +0x50f,
code.gitea.io/gitea/cmd.runWeb(0xc0000f6640, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/cmd/web.go:121 +0xaa,
code.gitea.io/gitea/vendor/github.com/urfave/cli.HandleAction(0x16369a0, 0x18c7550, 0xc0000f6640, 0xc000153e00, 0x0),
	/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:471 +0xad,
code.gitea.io/gitea/vendor/github.com/urfave/cli.Command.Run(0x18433f5, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x186d7f2, 0x16, 0x0, ...),
	/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/command.go:191 +0x97f,
code.gitea.io/gitea/vendor/github.com/urfave/cli.(*App).Run(0xc0000ae340, 0xc00000c060, 0x2, 0x2, 0x0, 0x0),
	/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:241 +0x5a2,
main.main(),
	/go/src/code.gitea.io/gitea/main.go:57 +0x438

During the wait, i’ll stick with version 1.6.
If there is anything I can do to help, please tell me.

I’ll try again with the 1.7.4 version in a week or so (when Archlinux gets it, since I use it on the production Arch server), fingers crossed.

This should be a bug I think.

The issue is still there with the 1.7.4 version - probably there are some pre-migration or post-migration hooks missing. I’ll stick with the 1.6.4 for time being and probably switch to gitlab-ce as a long term solution for my production git repos.

I have reviewed related codes and it’s some strange. Could you help to give some data on table repo_unit to help us track the issue.

Happy to help, but I’m very limited in Go. Just tell me what you need me to do and I’ll do it.

If you have any database knowledge, could you dump repo_unit table to me. That’s should not tell me your private message. You can contact me on discord.

Hey, sysadminmatmoz. Has the reason for this issue been identified yet?

Hello @lunny,
Here are the first few lines of the dump of my table repo_unit. I hope it is enough. In case not, I can send the whole file (~250 lines) to you.

$ sqlite3 gitea.db '.dump repo_unit'
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE `repo_unit` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `repo_id` INTEGER NULL, `type` INTEGER NULL, `config` TEXT NULL, `created_unix` INTEGER NULL);
INSERT INTO "repo_unit" VALUES(1,6,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(2,6,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);
INSERT INTO "repo_unit" VALUES(3,6,3,'{"AllowMerge":1,"AllowRebase":1,"AllowSquash":1,"IgnoreWhitespaceConflicts":0}',1491305853);
INSERT INTO "repo_unit" VALUES(5,6,4,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(6,6,5,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(8,7,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(9,7,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);
INSERT INTO "repo_unit" VALUES(10,7,3,'{"AllowMerge":1,"AllowRebase":1,"AllowSquash":1,"IgnoreWhitespaceConflicts":0}',1491305853);
INSERT INTO "repo_unit" VALUES(12,7,4,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(13,7,5,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(15,8,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(16,8,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);
INSERT INTO "repo_unit" VALUES(17,8,3,'{"AllowMerge":1,"AllowRebase":1,"AllowSquash":1,"IgnoreWhitespaceConflicts":0}',1491305853);
INSERT INTO "repo_unit" VALUES(19,8,4,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(20,8,5,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(22,9,1,'{}',1491305853);
INSERT INTO "repo_unit" VALUES(23,9,2,'{"AllowOnlyContributorsToTrackTime":1,"EnableDependencies":true,"EnableTimetracker":1}',1491305853);

[...]

INSERT INTO "repo_unit" VALUES(409,52,2,'{"EnableTimetracker":false,"AllowOnlyContributorsToTrackTime":false,"EnableDependencies":false}',1552321984);
INSERT INTO "repo_unit" VALUES(410,52,3,'{"IgnoreWhitespaceConflicts":true,"AllowMerge":true,"AllowRebase":true,"AllowSquash":true}',1552321984);
INSERT INTO "repo_unit" VALUES(416,80,1,NULL,1553707116);
INSERT INTO "repo_unit" VALUES(417,80,2,'{"EnableTimetracker":true,"AllowOnlyContributorsToTrackTime":true,"EnableDependencies":true}',1553707116);
INSERT INTO "repo_unit" VALUES(418,80,3,'{"IgnoreWhitespaceConflicts":false,"AllowMerge":true,"AllowRebase":true,"AllowSquash":true}',1553707116);
INSERT INTO "repo_unit" VALUES(419,80,4,NULL,1553707116);
INSERT INTO "repo_unit" VALUES(420,80,5,NULL,1553707116);
CREATE INDEX `IDX_repo_unit_s` ON `repo_unit` (`repo_id`,`type`);
CREATE INDEX `IDX_repo_unit_created_unix` ON `repo_unit` (`created_unix`);
COMMIT;

@Mageti Thanks very much.