[SOLVED] Gitea fails to start, migrations trying to downgrade database

Greetings,

I run gitea from the latest docker container and starting today when I try and bring up the gitea container it fails to come up. Not sure the best way to get the image version, docker inspect shows
"Image": "sha256:d31ed043681f8aa00c9a709e5bdd8ca5195e40a73e0b74251095a8b87d14a01e"
docker images show an IMAGE ID of d31ed043681f

Here’s the startup error message I get.

 docker-compose up gitea
Starting gitea ... done
Attaching to gitea
gitea                 | Server listening on :: port 22.
gitea                 | Server listening on 0.0.0.0 port 22.
gitea                 | 2022/01/29 21:37:25 cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 17
gitea                 | 2022/01/29 21:37:25 cmd/web.go:146:runWeb() [I] Global init
gitea                 | 2022/01/29 21:37:25 routers/init.go:76:GlobalInit() [I] Git Version: 2.30.2, Wire Protocol Version 2 Enabled
gitea                 | 2022/01/29 21:37:25 routers/init.go:79:GlobalInit() [I] AppPath: /app/gitea/gitea
gitea                 | 2022/01/29 21:37:25 routers/init.go:80:GlobalInit() [I] AppWorkPath: /app/gitea
gitea                 | 2022/01/29 21:37:25 routers/init.go:81:GlobalInit() [I] Custom path: /data/gitea
gitea                 | 2022/01/29 21:37:25 routers/init.go:82:GlobalInit() [I] Log path: /data/gitea/log
gitea                 | 2022/01/29 21:37:25 routers/init.go:83:GlobalInit() [I] Run Mode: Prod
gitea                 | Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity.
gitea                 | If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`
gitea                 | Received signal 15; terminating.

Checking my version from my sqlite db, I see version 209

sqlite> select * from version;
1|209

Checking the github repo github repo for gitea, it appears that db version 209 is a valid version (gitea/migrations.go at d7c2a2951c6a0a85f43675c83d3d639cd50eccb4 · go-gitea/gitea · GitHub)

Enabling debug logging in app.ini I get the following logs

2022/01/29 21:27:34 ...dules/setting/log.go:333:newLogService() [I] Gitea Log Mode: File(File:)
2022/01/29 21:27:34 ...dules/setting/log.go:249:generateNamedLogger() [I] Router Log: Console(console:)
2022/01/29 21:27:34 ...les/setting/cache.go:78:newCacheService() [I] Cache Service Enabled
2022/01/29 21:27:34 ...les/setting/cache.go:93:newCacheService() [I] Last Commit Cache Service Enabled
2022/01/29 21:27:34 ...s/setting/session.go:77:newSessionService() [I] Session Service Enabled
2022/01/29 21:27:34 ...es/setting/mailer.go:109:newMailService() [I] Mail Service Enabled
2022/01/29 21:27:34 ...es/setting/mailer.go:120:newRegisterMailService() [I] Register Mail Service Enabled
2022/01/29 21:27:34 ...es/setting/mailer.go:131:newNotifyMailService() [I] Notify Mail Service Enabled
2022/01/29 21:27:34 ...s/storage/storage.go:171:initAttachments() [I] Initialising Attachment storage with type:
2022/01/29 21:27:34 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/attachments
2022/01/29 21:27:34 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type:
2022/01/29 21:27:34 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/avatars
2022/01/29 21:27:34 ...s/storage/storage.go:183:initRepoAvatars() [I] Initialising Repository Avatar storage with type:
2022/01/29 21:27:34 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-avatars
2022/01/29 21:27:34 ...s/storage/storage.go:177:initLFS() [I] Initialising LFS storage with type:
2022/01/29 21:27:34 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/git/lfs
2022/01/29 21:27:34 ...s/storage/storage.go:189:initRepoArchives() [I] Initialising Repository Archive storage with type:
2022/01/29 21:27:34 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-archive
2022/01/29 21:27:34 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: push_update Starting
2022/01/29 21:27:34 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: mail Starting
2022/01/29 21:27:34 ...ueue_disk_channel.go:172:Run() [D] PersistableChannelQueue: push_update Skipping running the empty level queue
2022/01/29 21:27:34 ...ueue_disk_channel.go:172:Run() [D] PersistableChannelQueue: mail Skipping running the empty level queue
2022/01/29 21:27:34 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: notification-service Starting
2022/01/29 21:27:34 ...ue/queue_bytefifo.go:242:Shutdown() [D] level: push_update-level Shutdown
2022/01/29 21:27:34 ...ue/queue_bytefifo.go:242:Shutdown() [D] level: mail-level Shutdown
2022/01/29 21:27:34 ...ueue_disk_channel.go:172:Run() [D] PersistableChannelQueue: notification-service Skipping running the empty level queue
2022/01/29 21:27:34 ...ue/queue_bytefifo.go:242:Shutdown() [D] level: notification-service-level Shutdown
2022/01/29 21:27:34 ...ueue_disk_channel.go:162:Run() [D] PersistableChannelUniqueQueue: repo-archive Starting
2022/01/29 21:27:34 ...ueue_disk_channel.go:196:Run() [D] PersistableChannelUniqueQueue: repo-archive Skipping running the empty level queue
2022/01/29 21:27:34 ...ue/queue_bytefifo.go:242:Shutdown() [D] unique-level: repo-archive-level Shutdown
2022/01/29 21:27:34 routers/init.go:95:GlobalInit() [I] SQLite3 Supported
2022/01/29 21:27:34 routers/common/db.go:20:InitDBEngine() [I] Beginning ORM engine initialization.
2022/01/29 21:27:34 routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #1/10...
2022/01/29 21:27:34 ...om/urfave/cli/app.go:524:HandleAction() [I] PING DATABASE sqlite3
2022/01/29 21:27:34 ...ations/migrations.go:383:Migrate() [I] [SQL] SELECT name FROM sqlite_master WHERE type='table' and name = ? [version] - 72.652µs
2022/01/29 21:27:34 routers/common/db.go:28:InitDBEngine() [I] [SQL] SELECT * FROM version LIMIT 0 [] - 21.636µs
2022/01/29 21:27:34 routers/common/db.go:28:InitDBEngine() [I] [SQL] SELECT * FROM version LIMIT 0 [] - 12.171µs
2022/01/29 21:27:34 ...rm.io/xorm/engine.go:1139:Get() [I] [SQL] SELECT `id`, `version` FROM `version` WHERE `id`=? LIMIT 1 [1] - 82.445µs
2022/01/29 21:27:34 ...ations/migrations.go:414:Migrate() [F] Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity.
        If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`

Really confused about why this is failing to start. Seems like it’s detecting the correct version of the database? I don’t know. Any help is appreciated.

Same problem here although I’m running on MariaDB. Docker log shows

Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity.
If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`

The “may result in loss of data integrity” stopped me from blindly executing the command. Hope someone has an idea on how to get it fixed.

Upgraded the Docker image to the latest version today and now I’m getting the same error. Rolling back to another tag doesn’t work either.

I’ll restore from a backup until this is fixed.

Same problem here. Seems docker :latest tag was pointing to 1.16rc release (which updated database to 209), but they then changed :latest to point to 1.15 again.

Either you have to restore a DB version from before the change to 1.16.0-rc1 or you have to change your docker image URL to pull 1.16.0-rc1

Docker :latest tag referred to 1.16.0-rc1, now it refers to 1.15.11 (downgrade) · Issue #18462 · go-gitea/gitea (github.com)

As a temporary workaround I went with a suggestion from Discord and pulled 1.16.0.rc1 image. This seems to resolve the db version issue in stable release.

We accident pushed 1.16-rc1 to :latest but it should not be there. So I think there are two workrounds currently.

  1. If you want to still follow :latest , please go to database and change the version table value to 189 and restart.
  2. if you don’t want to change database manually, please change the docker tag to 1.16-rc1 , and you can change back when 1.16.0 is released.

I recommand to use the second , there is some risk for the first workround.

I’m very sorry for that problem confusing you.

2 Likes

Changing the docker tag to gitea:1.16.0-rc1 worked perfectly for me. I’ll watch it and once latest is caught up again I’ll switch back over to that. Thanks a ton @lunny

1 Like

I had similar issues. solved it by running a db update in Maria. take a look at RESOLVED: Gitea DB Migration Failure DockerImage is Latest

As 1.16.0 released, all of them are solved now. You can switch to :latest from 1.16.0-rc1.