gitea: Upgrade from 1.20.0-rc0 to 1.20.0 fails: Deprecated fallback present

Description

I just did a docker pull of :latest and docker-compose down/up the container and I get this. I was able to resolve by pinning it to 1.20.0-rc0 but 1.20.0-rc1 and rc2 failed as well as :latest which is currently 1.20.0.

Attaching to gitea_web
gitea_web | 2023/07/16 22:51:24 …s/setting/setting.go:180:loadRunModeFrom() [F] Gitea is not supposed to be run a s root. Sorry. If you need to use privileged TCP ports please instead use setcap and the cap_net_bind_service permission
gitea_web | Server listening on :: port 22.
gitea_web | Server listening on 0.0.0.0 port 22.
gitea_web | 2023/07/16 22:51:24 …g/config_provider.go:327:deprecatedSettingFatal() [F] Deprecated fallback [serv er] LFS_CONTENT_PATH present. Use [lfs] PATH instead. This fallback will be/has been removed in v1.19.0
gitea_web | Received signal 15; terminating.
gitea_web | 2023/07/16 22:51:24 …s/setting/setting.go:180:loadRunModeFrom() [F] Gitea is not supposed to be run a s root. Sorry. If you need to use privileged TCP ports please instead use setcap and the cap_net_bind_service permission
gitea_web | Server listening on :: port 22.
gitea_web | Server listening on 0.0.0.0 port 22.
gitea_web | 2023/07/16 22:51:25 …g/config_provider.go:327:deprecatedSettingFatal() [F] Deprecated fallback [serv er] LFS_CONTENT_PATH present. Use [lfs] PATH instead. This fallback will be/has been removed in v1.19.0
gitea_web | Received signal 15; terminating.
gitea_web | 2023/07/16 22:51:25 …s/setting/setting.go:180:loadRunModeFrom() [F] Gitea is not supposed to be run a s root. Sorry. If you need to use privileged TCP ports please instead use setcap and the cap_net_bind_service permission
gitea_web | Server listening on :: port 22.
gitea_web | Server listening on 0.0.0.0 port 22.
gitea_web | 2023/07/16 22:51:25 …g/config_provider.go:327:deprecatedSettingFatal() [F] Deprecated fallback [serv er] LFS_CONTENT_PATH present. Use [lfs] PATH instead. This fallback will be/has been removed in v1.19.0
gitea_web | Received signal 15; terminating.
gitea_web | 2023/07/16 22:51:26 …s/setting/setting.go:180:loadRunModeFrom() [F] Gitea is not supposed to be run a s root. Sorry. If you need to use privileged TCP ports please instead use setcap and the cap_net_bind_service permission
gitea_web | Server listening on :: port 22.
gitea_web | Server listening on 0.0.0.0 port 22.
gitea_web | 2023/07/16 22:51:26 …g/config_provider.go:327:deprecatedSettingFatal() [F] Deprecated fallback [serv er] LFS_CONTENT_PATH present. Use [lfs] PATH instead. This fallback will be/has been removed in v1.19.0
gitea_web | Received signal 15; terminating.

Gitea Version

1.20.0

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

1.20.0

Operating System

EL8

How are you running Gitea?

docker

Database

None

About this issue

Original URL
State: closed
Created a year ago
Reactions: 8
Comments: 22 (6 by maintainers)

Commits related to this issue

Add shutting down notice (#25920) Got the same problem as #25915 when updating an instance. The `log.Fatal` should have been marked as breaking in #23911. This PR adds a notice that the system is... — committed to go-gitea/gitea by KN4CK3R a year ago
Add shutting down notice (#25920) Got the same problem as #25915 when updating an instance. The `log.Fatal` should have been marked as breaking in #23911. This PR adds a notice that the system is... — committed to GiteaBot/gitea by KN4CK3R a year ago
Add shutting down notice (#25920) (#25922) Backport #25920 by @KN4CK3R Got the same problem as #25915 when updating an instance. The `log.Fatal` should have been marked as breaking in #23911. ... — committed to go-gitea/gitea by GiteaBot a year ago
Display deprecated warning in admin panel pages as well as in the log file (#26094) (#26154) backport #26094 Temporily resolve #25915 Related #25994 This PR includes #26007 's changes but have ... — committed to go-gitea/gitea by lunny a year ago

Most upvoted comments

Having the same issue, did this to app.ini solved it:

Old app.ini:

[server]
APP_DATA_PATH=/data/gitea
...
LFS_START_SERVER=true
LFS_CONTENT_PATH=/data/git/lfs
LFS_JWT_SECRET=xxx

New app.ini:

[lfs]
PATH=/data/git/lfs


[server]
APP_DATA_PATH=/data/gitea
...
LFS_START_SERVER=true
LFS_JWT_SECRET=xxx

+19

ternium1 on Jul 18, 2023

The error message tells you explicitly what you need to do:

Deprecated fallback [server].LFS_CONTENT_PATH present. Use [lfs].PATH instead. This fallback has been removed in v1.19.0

So, go to your app.ini and change that.

delvh on Jul 16, 2023

Just also reproduced this – pulling the 1.20 container breaks, whereas pinning to 1.20.0-rc0 makes it work again. So something screwed up in the built container.

x86dev on Jul 18, 2023

The error message tells you explicitly what you need to do:

Deprecated fallback [server].LFS_CONTENT_PATH present. Use [lfs].PATH instead. This fallback has been removed in v1.19.0

So, go to your app.ini and change that.

If you’re just using docker without any sort of config file how would you change it?

Edit: My /data directory exists on a docker volume and the image won’t start due to this error, it’s a pretty breaking change for users who had their configs from previous installations.

TWDickson on Jul 18, 2023

That fix does not work if you use the default container with no custom app.ini.

x86dev on Jul 19, 2023

Regarding the Docker users: If I’ve understood it correctly, there seems to be another issue in that the default Docker file comes with an app.ini that still sets a removed setting, right? If that’s the case, then that’s a bug we should fix

That’s my exact scenario, my docker-compose has no app.ini supplied and the /data directory is just set to a docker volume.

TWDickson on Jul 19, 2023

Yes. This warning is explicitly meant to notify admins that such config options no longer have any effect. This prevents the situation that settings are no longer in effect that admins thought they set. That’s why this warning is crashing Gitea as intended when the setting is present.

After all, there are three ways to handle breaking config changes (that I see as viable):

Annoy admins slightly whenever they upgrade to fix their now outdated config to keep up to date
Carry old config options for quite a while and annoy admins a lot by removing all legacy options for several releases at once
Carry all old config options forever, and make the code effectively unmaintainable and unpredictable

Gitea currently chooses option 1.. I didn’t go into detail about this error message previously in this issue as I thought my previous comment would suffice to let you know what happened, and how you can fix it. Apparently I was wrong here. Sorry about that.

Regarding the Docker users: If I’ve understood it correctly, there seems to be another issue in that the default Docker file comes with an app.ini that still sets a removed setting, right? If that’s the case, then that’s a bug we should fix.

delvh on Jul 19, 2023

The cause and the solution is clear, but the container image just isn’t up-to-date 😉

x86dev on Jul 19, 2023

Same issue as above in regards to updated Docker

stoofz on Jul 18, 2023

You can edit the files in the volume even if the container is not running.

KN4CK3R on Jul 20, 2023

what a weird change

realies on Jul 19, 2023