Linux 2.6.26-2-amd64 : FATAL: kernel too old #4131
Comments
|
Gitea it doesn't ask special linux kernel version. I think that's Go's requirement. And maybe the golang's wiki is not updated? |
lunny
added
the
status/blocked
|
That's not correct. It's because the binary is statically linked, for GNU/Linux 2.6.32 Rubens-MacBook-Pro:~ ruben$ cat hello.go
package main
func main() {
println("hello world")
}
Rubens-MacBook-Pro:~ ruben$ GOOS=linux GOARCH=amd64 go build hello.go
~# uname -a
Linux tcc.intern.drachenfels.de 2.6.26-2-amd64 #1 SMP Sun Mar 4 21:48:06 UTC 2012 x86_64 GNU/Linux
~# ./hello
hello world
~# file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped |
|
That depends on your go version, older go versions had lower kernel requirements, check your go version |
|
I used the precompiled version form the download page and didn't compile gitea myself. |
|
@r10r That's what he actually meant. Since in your example you compile code yourself with your installed go version, which may be older than the one we use to build the binary. |
|
Rubens-MacBook-Pro:~ ruben$ go version |
|
What version did you use? |
|
we use 1.10.2, see Line 4 in 2fcd9b6 |
|
I've installed 1.10.2, recompiled the example and it still works ... |
|
Apart from that the Makefile build target does not cross-compile on OSX. When I build it without the Makefile it builds: but raises another error on the server: |
|
you need to build using |
|
Your gopath haven't set up correctly. |
|
You can find how to build from source, see https://docs.gitea.io/en-us/install-from-source/ |
|
Just want to let you know, that I get this message when updating our gitea 1.7.4 to 1.7.5 on one of our CentOS6 machines. To us this is not very dramatic as we intend to migrate to a more recent OS, but maybe some other users are affected too... |
|
@gerricom Confirmed. We were forced to downgrade to gitea 1.7.4. |
|
Yes, the change is that the docker image we use to cross-compile our binaries has been updated from Ubuntu 14.04 to 18.04 as 14.04 is End of life in a few days. However now that we have updated to use go modules, compiling from source yourself is much easier. You can git clone this repo and run |
|
I have this issue with Gitea 1.7.5; had to go to 1.7.4. Kernel version is 2.6.32 (because OpenVZ sucks) |
thank goodness. that one was tough |
|
Peeps, compiling from source isn't too difficult. Staying on 1.7.4 is not a good idea - our development is pretty rapid and although we've patched a lot of security bugs since the split with gogs, there was one in 1.7.4 that we've fixed in 1.7.5. @techknowlogick is there no way we can reduce the kernel requirements on the build? |
|
@zeripath Just this process wasn't fluent enough, I personally got some weird errors without solution in World Wide Web, which were not related to the lack of build-essential tools. IMO if existing core is not accepted and build is barely successful on OpenVZ with Ubuntu 16.04, I have to stick to 1.7.4 binary... or switch VPS provider maybe. |
Same problem with the binary here - i think quite many users want to run gitea on an OpenVZ vServer ... I've getting the following erros by compiling from source with both I am usually not compiling things - maybe someone can give me a hint what i can do to solve this? |
|
I have just compiled gitea myself. There are instructions on the website on how to do this. |
|
@CMiksche your errors appear very odd and suggest to me that you have a very old version of go. What is your version of go? Just get the latest you can but at least go 1.9 Make sure you set the GOPATH and add its /bin to your PATH I presume you obtained your Gitea source code using the go command: For building the simplest and recommended thing to do: If you really don't need sqlite you can drop those tags. If you don't drop em you'll need a GCC to build the sqlite library. |
|
@vintprox if you would like to suggest changes to https://docs.gitea.io/en-us/install-from-source/ we're happy to improve it, but it does say about tags and releases. What were your strange errors? Master is on the whole relatively stable - apart from around database schema changes necessitating migration script changes. (These unfortunately tend to break a few users because real life data is so much more complex so it's almost impossible to completely get the script right first time and a few users always have a bumpy ride till we get it right.) |
Thank you. Exactly that was my problem (used Go Version 1.7.4) |
|
@CMiksche glad that fixed it for you. I guess we could try to put something in to throw an understandable error if you try to compile with a go that's too old. I think this is relatively easy to add if you compile with make but it's probably preferable to get go build to barf itself. |
|
Tried to build from source using instructions from #4131 (comment) resulted in Go version 1.11.5 |
|
Why couldn't you use make ? I really did spend quite a bit of time rewriting the instructions in https://docs.gitea.io/en-us/install-from-source/ to make them as foolproof as possible. You wouldn't have to download any of these if you'd just used the make file. If you really don't want to use the make file then you should add a If you don't want to do that then you'll just have to try again. The failure you're getting is not our fault, it's with googlesource.com . If trying again doesn't work you may have to fund where the partially broken partially downloaded repo golang.org/x/net has been put and just delete it, then try again. Possibly it's in the GOPATH but I don't know. |
|
Hello @zeripath, I downloaded nothing manually, just the source file of release 1.7.6, unpacked it, cd'ed into gitea-1.7.6 and executed the go build command. Nothing more, but I tried it multiple times because my first intention was that there was an incomplete git pull or something like that. I tried it now using make but result is still the same: Removing the directory ~/go recursively seems also not solving the problem. :( Everything I try results in the same problematic package. I will now give the git repository a try, but I think a build against a release tarball should be repeatable (in case of all requirements still exists) all of the time. BTW: I never told that there is a problem in your source or configs. I just want to ask for help :) |
|
Sorry if I sounded annoyed. Delete (Which implies you're building as root? Please don't do so much as root it's a really bad idea!) |
|
Hello again and sorry for late feedback. It took some sparetime to update git to a newer version because the previous was a little bit too old and I thought it could be a reason of build errors. Now I have installed 2.21.0 \o/ Then I switched from zip file to git repo with branch release/v1.7 and gave it a try. But there is still an issue which prevents from finishing build successful: Is it correct, that the following line causes the problem? I tried it two and three times with and without removing ~/go directory but error is still the same. If I add the argument -mod=vendor I'm getting always reproducable Do you have a hint, what I'm doing wrong? BR |
|
OK, Let's do this completely by the book. Stop downloading zips and tar.gz. Read: https://docs.gitea.io/en-us/install-from-source/ . Ensure that go get -d -u code.gitea.io/gitea
cd "$GOPATH/src/code.gitea.io/gitea"
git checkout v1.7.6
TAGS="bindata sqlite sqlite_unlock_notify" make generate buildGo is very opinionated on where it expects things to be. Yes with modules you should be able to download outside of the |
|
Thank you for support :) First try resulted in error, that go-bindata was not found: I have an RPM package of go installed which was available in repository. That package does not provide the binary. So I installed go-bindata.x86_64 and executed make again. This resulted in obviously too old go-bindata binary: Same error for modules/public/public.go:20 and modules/templates/templates.go:7 I have version I will try to update the go-bindata and give feedback asap. |
|
I had the same problem (too old kernel 2.6.32.x on Ubuntu 16.04 LTS on OpenVZ). While my disappointment is with my OpenVZ host (not Gitea) I was able to build from source based on the documentation steps. If I understand, the requirements are golang >=1.9.x, go-bindata (not sure what version), and make. I am very new to Gitea, so welcome corrections if I have overlooked something in these steps |
|
I updated go-bindata to 3.1.0 and now it builds successfully. Thank you. |
|
So I installed Gitea 1.7.4 some time ago using this guide. Now when trying to upgrade to 1.8.1 I get the "FATAL: kernel too old" error. Does this mean I need to reset the server and build from source all over again? Or can this be fixed without having to go through all that again? |
|
@PlanetRenox, to give you a valid answer, you need to provide more information about your system. Which distribution, which kernel do you use? Which output you get by executing $> uname -aLong story short: The build executable by the gitea team does not support linux kernel with version 2.6. In case you use such a kernel with 64bit I could provide you a pre-built executable. |
|
@maikgreubel Using the guide I linked I basically built Gitea 1.7.4 from binary on CentOS 7 Here is my output for
What should I do? If you provide me a pre-built executable please also let me know how to not lose user/repo data that is already on the server. (db type: sqlite3) |
|
@PlanetRenox, you can try https://packages.nkey.de/gitea/gitea-1.8.2-amd64-linux26.xz
HTH |
|
@techknowlogick could we do additional builds on a centos docker? |
|
@maikgreubel it worked. gj How did you figure that out? What do I do for future updates? |
|
@PlanetRenox, you are welcome :) I can only direct you to the question I asked and the answers I got in this thread here, to answer your question how I figured it out ;) @zeripath asked the question to support the old kernel 2.6 using docker builds. This would be a great solution. In any other case each user of us will need to compile the stuff by itself. Or someone in the community is willing to do it in future and provide a built binary. So it depends on what the result of discussion to use docker build will be. A community member provided binary will be fine but it is a not so optimal solution from security and trust point of view. |
|
I removed the go-bindata dependent on #7080 I have created a repository to compile go repository with gcc. It's based on a recent centos image, see https://gitea.com/lunny/centos-go and https://cloud.docker.com/u/lunny/repository/docker/lunny/centos-go |
|
I will close this issue and please feel free to reopen it. |
[x]):Description
~# ./gitea-1.4.2-linux-amd64 -h
FATAL: kernel too old
Segmentation fault
~# file gitea-1.4.2-linux-amd64
gitea-1.4.2-linux-amd64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, from '8@1600(%rax) 8@1608(%rax)', not stripped
...
I expect that gitea has Go's minimum requirements.
Otherwise it would be nice to add a note somewhere that kernel must be >= 2.6.32 https://github.com/golang/go/wiki/MinimumRequirements#linux
The text was updated successfully, but these errors were encountered: