-
-
Notifications
You must be signed in to change notification settings - Fork 6k
Closed
Labels
issue/needs-feedbackFor bugs, we need more details. For features, the feature must be described in more detailFor bugs, we need more details. For features, the feature must be described in more detail
Description
Description
Git push always fails with error:
git push origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 209 bytes | 209.00 KiB/s, done.
Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
remote:
remote: Gitea: Internal Server Error
To http://192.168.1.99:3000/user/test.git
! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 'http://192.168.1.99:3000/user/test.git'
Gitea Version
Gitea version 1.17.3+4-g19df07f02 built with GNU Make 4.1, go1.18.7 : bindata, sqlite, sqlite_unlock_notify
Git Version
2.37.3
Operating System
Arch Linux
How are you running Gitea?
Binary download, fresh install, no containers.
Database
SQLite
Metadata
Metadata
Assignees
Labels
issue/needs-feedbackFor bugs, we need more details. For features, the feature must be described in more detailFor bugs, we need more details. For features, the feature must be described in more detail
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
lunny commentedon Oct 21, 2022
You can enable RUN_MODE as dev and try again to take a look at what's the error.
Dynabits commentedon Oct 21, 2022
Output with RUN_MODE set to dev
Dynabits commentedon Oct 21, 2022
Ahh I see, looks like a post request is made with localost in the URL, that should be the IP address, not sure how to fix though.
lunny commentedon Oct 21, 2022
Because the host don't know what
localhost
means. Your /etc/hosts should be checked.Dynabits commentedon Oct 21, 2022
I added this line to /etc/hosts
Works like a charm now, thank you so much @lunny
codeex commentedon Oct 31, 2022
on windows platform, it has the same error :Gitea: Internal Server Error
Unable to contact gitea: Post "http://localhost:3000/api/internal/hook/pre-receive/hhh/test": dial tcp: lookup localhost on 114.114.114.114:53: no such host.
I've modified C:\Windows\System32\drivers\etc\hosts, and added
127.0.0.1 localhost
but it has the same error, I don't know what I do again?
lunny commentedon Oct 31, 2022
It's a domain problem.
jackzhum commentedon Nov 14, 2022
I have the same problem. How can I solve it?
jackzhum commentedon Nov 14, 2022
I solved this problem: I will LOCAL_ ROOT_ The URL is changed to be the same as ROOT_ URL consistency.
jinyangcruise commentedon Jan 8, 2023
@jackzhum
I have the same problem. what is "LOCAL_ ROOT_ "? I can not find a LOCAL_ in my app.ini.
here is my my app.ini content:
jackzhum commentedon Jan 16, 2023
https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini

zeripath commentedon Jan 16, 2023
THOSE EXPERIENCING THIS ON WINDOWS IN 1.18 - YOU ARE EXPERIENCING A DUPLICATE OF #22370
Please see #22370 (comment)
DESCRIPTION
This bug is due to a change in Go's handling of the
netgo
build tag for Windows see:#22370 (comment)
We were bitten by this because we build our static precompiled binaries with
netgo
for all platforms. (see #22370 (comment))#22467 and #22468 should fix this for 1.18.1 and 1.19-dev.
WORKAROUND
For 1.18.0 set the
GODEBUG=netdns=cgo
environment variable when running gitea and/or update your LOCAL_ROOT_URL to use an IP address#22370 (comment)
Builds of what will become 1.18.1 are available now on https://dl.gitea.io/gitea/1.18
gilbertoca commentedon Jan 27, 2023
In our case, bringing our server from gitea-1.16.9-linux-amd64 to gitea-1.17.4-linux-amd64, we needed to remove that parameter:
#LOCAL_ROOT_URL = https://localhost:3000/
Maybe is not just a windows problem? @zeripath
zeripath commentedon Jan 27, 2023
@gilbertoca on 1.18 this bug was one of a cluster of issues opened due to a change in the way Golang handles the build tag
netgo
in Golang 1.18. This broke IP lookup of localhost.Whatever issue you were experiencing is different and if you're still experiencing you should consider opening a separate bug report with complete information about what your experience is. However, 1.17 is now out of support so you would need to show that your problem existed on 1.18 too. On 1.17 as was originally experienced this was due to missing alias for 127.0.0.1 in /etc/hosts.
The other thing to note - is that your problem was solved by doing the opposite to how this bug was worked around for others. That your solution requires the opposite says that the problem is likely a different thing.
In any case I'm going to lock this conversation - this bug is resolved and was a duplicate of #22730