Add support for 4.19 LTS kernel

[freeseacher]

Currently build on buster is broken
release/ebpf_exporter-1.2.1-dev/ebpf_exporter: symbol lookup error: release/ebpf_exporter-1.2.1-dev/ebpf_exporter: undefined symbol: bcc_prog_load

build with that diff to Dockerfile

diff --git a/Dockerfile b/Dockerfile
index 9c8a01f..f926190 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,4 +1,4 @@
-FROM golang:1.12.6-stretch
+FROM golang:1.12.14-buster
 
 # Doing mostly what CI is doing here
 RUN apt-get update && \
@@ -6,7 +6,7 @@ RUN apt-get update && \
     apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 648A4A16A23015EEF4A66B8E4052245BD4284CDD && \
     echo "deb https://repo.iovisor.org/apt/xenial xenial main" > /etc/apt/sources.list.d/iovisor.list && \
     apt-get update && \
-    apt-get install -y libbcc=0.10.0-1 linux-headers-amd64
+    apt-get install -y libbcc=0.10.0-1 linux-headers-amd64 libtinfo5
 
 COPY ./ /go/ebpf_exporter

[bobrik]

This has nothing to do with the kernel and everything to do with dynamic linking.

We install libbcc provided by bcc project and it's built on Ubuntu Xenial, where ncurses5 is used. You can see it linked to /bin/bash (libtinfo.so.5):

$ docker run --rm ubuntu:xenial ldd /bin/bash
	linux-vdso.so.1 =>  (0x00007ffedc69b000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f33d90af000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f33d8eab000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f33d8ae1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f33d92d8000)

You are trying to build it on Debian Buster, which upgraded to ncurses6 (libtinfo.so.6):

$ docker run --rm debian:buster ldd /bin/bash
	linux-vdso.so.1 (0x00007ffce038b000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f2988c0f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2988c0a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2988a49000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2988d69000)

You can still install ncurses5 which your fix is all about.

The proper way of isolating this issue is to link everything statically, so you don't care which distro is used for building and binary can run on any.

Unfortunately there are no archives produced in debian packages for libbcc for us to do so:

• Statically compiling libbcc iovisor/bcc#1938

The next best thing to static linking is building ebpf_exporter in the environment where you want to run it, but we can't really do this for everybody and you have to do it yourself. It appears that it's what you're doing and if the fix works for you, then you should stick to that.

The binary provided in releases is on best effort basis and currently it may work on both Stretch and Buster (with ncurses5 additionally installed). If we upgrade to Buster, then Stretch would't be able to use that binary at all.