Gitea: migration from version 1.8.3 to version 1.9.0 fails

[wumpz]

• Gitea version (or commit ref): 1.9.0
• Operating system: linux / docker
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [x] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist:

Description

I have a running 1.8.3 gitea docker server. All works fine. Now I wanted to upgrade to the new version 1.9.0. The server seems to be in a neverending loop initializing itself. All I see in my docker logs is repeatingly endless.

gitea_server_1  | 2019/08/01 05:59:58 ...dules/setting/git.go:83:newGit() [I] Git Version: 2.22.0, Wire Protocol Version 2 Enabled
gitea_server_1  | 2019/08/01 05:59:58 routers/init.go:72:GlobalInit() [T] AppPath: /app/gitea/gitea
gitea_server_1  | 2019/08/01 05:59:58 routers/init.go:73:GlobalInit() [T] AppWorkPath: /app/gitea
gitea_server_1  | 2019/08/01 05:59:58 routers/init.go:74:GlobalInit() [T] Custom path: /data/gitea
gitea_server_1  | 2019/08/01 05:59:58 routers/init.go:75:GlobalInit() [T] Log path: /data/gitea/log
gitea_server_1  | 2019/08/01 05:59:58 ...dules/setting/log.go:226:newLogService() [I] Gitea v1.9.0 built with GNU Make 4.2.1, go1.12.7 : bindata, sqlite, sqlite_unlock_notify

Where should I look for additional informations? Logs?

[wumpz]

By the way, switching back to version 1.8.3 the server starts again like a breeze.

[wumpz]

Within the log file, I found this SQL after which a rollback is done.

2019/08/01 06:00:25 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] BEGIN TRANSACTION
2019/08/01 06:00:25 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT `id`, `uid`, `name`, `sha1`, `token_hash`, `token_salt`, `token_last_eight`, `created_unix`, `updated_unix` FROM `access_token` LIMIT 100
2019/08/01 06:00:25 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] COMMIT
2019/08/01 06:00:25 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] BEGIN TRANSACTION
2019/08/01 06:00:25 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] PRAGMA index_list(`access_token`)
2019/08/01 06:00:25 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] PRAGMA index_info(`IDX_access_token_updated_unix`)
2019/08/01 06:00:25 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] PRAGMA index_info(`IDX_access_token_created_unix`)
2019/08/01 06:00:25 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] PRAGMA index_info(`IDX_access_token_uid`)
2019/08/01 06:00:25 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] SELECT sql FROM sqlite_master WHERE tbl_name='access_token' and type='table'
2019/08/01 06:00:25 .../xorm/session_raw.go:226:Exec() [I] [SQL] CREATE TABLE `new_access_token_new` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `uid` INTEGER NULL, `name` TEXT NULL, `token_hash` TEXT NULL, `token_salt` TEXT NULL, `token_last_eight` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL,
2019/08/01 06:00:25 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] ROLL BACK
2019/08/01 06:00:25 routers/init.go:58:initDBEngine() [I] Backing off for 3 seconds
2019/08/01 06:00:28 routers/init.go:51:initDBEngine() [I] ORM engine initialization attempt #2/10...

[zeripath]

I suspect this is an error in droptables - #6849 but why it's not been caught by our migration tests I don't understand.

[wumpz]

@zeripath So can I provide additional information to tackle this problem? I really want to upgrade. ;)

[phamilton4321]

Any workaround available? I'm on 1.8.3 with sqlite and can't upgrade to 1.9.0 too because of database errors...

[wumpz]

@phamilton4321 as far as I know, the patch is already available and I think it will be there in the next release.

[phamilton4321]

@wumpz okay, thx. I'll stay patient, 1.8.3 Ist more than awesome for me 😁

[lonix1]

I have the same problem when upgrading from 1.7.5

[wumpz]

In which version will this be integrated?

[lafriks]

1.9.1

[phamilton4321]

Did updating from 1.8.3 to 1.9.1 work for everybody? I'm having the same error as I had while updating to 1.9.0...

[wumpz]

Update from 1.8.3 to 1.9.1 worked. Gitea started so far I understand it. The webfront end pops up and shows version 1.9.1. No more error messages within the log.

I am using a docker image of Gitea. Maybe there is still a difference.

[phamilton4321]

Okay, then it might be an issue with my current db. I'm going to check if I can fix it manually.
Thanks anyways

Edit: Created an empty database with 1.9.1 and restored my data from gitea dump sql.
All good now on 1.9.1

[dunklesToast]

Upgraded from 1.4.3 to 1.9.3. Having the same issue

2019/10/11 16:19:08 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] COMMIT
2019/10/11 16:19:08 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] BEGIN TRANSACTION
2019/10/11 16:19:08 .../xorm/session_raw.go:143:queryBytes() [I] [SQL] SHOW INDEX FROM issue WHERE column_name IN ('assignee_id')
2019/10/11 16:19:08 .../xorm/session_raw.go:226:Exec() [I] [SQL] DROP INDEX `` ON `issue`
2019/10/11 16:19:08 ...xorm/xorm/session.go:845:saveLastSQL() [I] [SQL] ROLL BACK
2019/10/11 16:19:08 routers/init.go:86:GlobalInit() [F] ORM engine initialization failed: migrate: do migrate: Error 1091: Can't DROP ''; check that column/key exists

[guillep2k]

@dunklesToast Please try migrating to intermediate versions (especially before 1.6.0) and let us know which was the latest you could upgrade to. Also, if you could try "SELECT version FROM version", it would help.

[zeripath]

@dunklesToast I think I might understand what's going on here!

What database are you using? It's MYSQL right?

[zeripath]

I think it's looking for the index, not finding one, but then still trying to remove the index

[dunklesToast]

@guillep2k tried that already. With Version 1.5.0 I am getting this error:

Log Mode: File(Info)
2019/10/12 00:00:22 [I] XORM Log Mode: File(Info)
2019/10/12 00:00:22 [I] Cache Service Enabled
2019/10/12 00:00:22 [I] Session Service Enabled
2019/10/12 00:00:22 [I] Migration: Reformat and remove incorrect topics
2019/10/12 00:00:22 [I] This migration could take up to minutes, please be patient.
2019/10/12 00:00:22 [...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

@zeripath Yep, MySQL. Do you think adding the index manually will fix this?

[zeripath]

The causative code is:

https://github.com/go-gitea/gitea/blob/ac3613b791884f29c386bda2ccaad5c7434d822c/models/migrations/migrations.go#L398-L423

In particular
https://github.com/go-gitea/gitea/blob/ac3613b791884f29c386bda2ccaad5c7434d822c/models/migrations/migrations.go#L406-L407

I think I thought it would not return any results if there was no index. Clearly I was wrong.

Simple bug fix add between 406 and 407:

if strings.Trimspace(indexname) == "" {
  continue
}

Probably doesn't need the Trimspace.

Anyone fancy putting a PR up?

[guillep2k]

A quick PR? NP. 😁

[dunklesToast]

Thanks!
So now I have to wait until this is merged, a new version was compiled and then can I update or is there any hot fix / dirty patch so I can migrate to 1.9?

[guillep2k]

@dunklesToast First the PR must be approved. Then one of the owners will assign a milestone for it. Depending on the milestone they may request a backport. And then we must wait until the target release is done.

I don't know how desperate you are 😁, but if you don't want to wait, you could pull the 1.9.4 tag, apply the diff from that PR (it's only a couple of lines), compile and run. That should make it pass the upgrade part. If it works, then you can download and use a vanilla 1.9.4 to stay "standard".

[robin-thoni]

What's the status on this? I'm also trying to upgrade from 1.7 and getting the same loop...

[jolheiser]

@robin-thoni This issue has (reportedly) been fixed.
Can you please open a new issue with more details? Feel free to link to this one for reference.

[zeripath]

Please only migrate to the last point release of a series - so from 1.8.x to 1.9.5 not to 1.9.0. The broken migrations can only be fixed in later point releases - we can't re-release.