gitea: Linux 2.6.26-2-amd64 : FATAL: kernel too old

  • Gitea version (or commit ref): 1.4.2
  • Git version: 1.7.10.4
  • Operating system: Linux 2.6.26-2-amd64 #1 SMP Sun Mar 4 21:48:06 UTC 2012 x86_64 GNU/Linux
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • [x ] Not relevant
  • Log gist:

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

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 1
  • Comments: 44 (19 by maintainers)

Most upvoted comments

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)

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.

> file gitea-1.7.4
gitea-1.7.4: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, not stripped

> file gitea-1.7.5
gitea-1.7.5: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, not stripped

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…

I removed the go-bindata dependent on https://github.com/go-gitea/gitea/pull/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

@PlanetRenox, you can try https://packages.nkey.de/gitea/gitea-1.8.2-amd64-linux26.xz

  • unpack using xz -d
  • stop your gitea service
  • create a backup of current gitea binary (don’t know, where it lives on your system, use find / -name gitea -type f)
  • replace current binary using unpacked version
  • start your gitea service
  • test access

HTH

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.

## prepare the system dependencies
# apt-get install make
$ wget https://dl.google.com/go/go1.12.4.linux-amd64.tar.gz
# tar -C /usr/local -xzf go1.12.4.linux-amd64.tar.gz
$ export PATH=$PATH:/usr/local/go/bin # (actually set this in global /etc/profile.d/10-go.sh)
$ export GOPATH=/home/$USER/go
## prepare the go-bindata dependency
$ go get github.com/jteeuwen/go-bindata
$ cd $GOPATH/src/github.com/jteeuwen/go-bindata/go-bindata
$ go build
# cp /home/$USER/go/src/github.com/jteeuwen/go-bindata/go-bindata/go-bindata /usr/local/go/bin/go-bindata
## build gitea from source
$ cd; go get -v -d -u code.gitea.io/gitea
$ git checkout v1.8.0
$ TAGS="bindata" make generate build

I am very new to Gitea, so welcome corrections if I have overlooked something in these steps

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 $GOPATH is set - probably $HOME/go. Ensure that $GOPATH/bin is on the $PATH.

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 build

Go is very opinionated on where it expects things to be. Yes with modules you should be able to download outside of the $GOPATH but let’s stick with what we know works for the moment.

@techknowlogick could we do additional builds on a centos docker?

@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.